Nowe przepisy unijnego Data Act (Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2023/2854) wprowadzają jednolite zasady dotyczące przenoszenia usług przetwarzania danych pomiędzy dostawcami chmurowymi.
W centrum uwagi znajduje się art. 30 DA, który reguluje techniczne aspekty zmiany dostawcy usług chmurowych, różnicując obowiązki w zależności od modelu świadczenia usługi: IaaS, PaaS, SaaS oraz XaaS.
Celem tego przepisu jest zagwarantowanie użytkownikom chmury – w tym przedsiębiorcom – realnej możliwości zmiany dostawcy bez utraty danych, funkcjonalności i ciągłości działania systemów.
1. Ogólna charakterystyka art. 30 Data Act
Art. 30 DA dotyczy technicznych aspektów przenoszenia usług przetwarzania danych (tzw. data portability between providers). Ustawodawca unijny uznał, że brak interoperacyjności i zamknięte środowiska technologiczne utrudniają konkurencję, a użytkownicy często pozostają „uwięzieni” u jednego dostawcy.
Dlatego Data Act nakłada na dostawców różne obowiązki techniczne, zależne od modelu świadczenia usług:
- IaaS (Infrastructure as a Service) – dostawca udostępnia jedynie skalowalne zasoby infrastrukturalne, takie jak serwery, pamięć, sieci, wirtualne zasoby obliczeniowe. Nie oferuje oprogramowania ani aplikacji.
Klient samodzielnie zarządza systemem operacyjnym, oprogramowaniem pośredniczącym (middleware) i aplikacjami. - PaaS (Platform as a Service) – dostawca oprócz infrastruktury oferuje także środowisko programistyczne i oprogramowanie do wdrażania aplikacji. Klient korzysta z gotowej platformy, na której może rozwijać własne rozwiązania.
- SaaS (Software as a Service) – dostawca udostępnia użytkownikowi gotowe aplikacje, zarządzając całą infrastrukturą, oprogramowaniem i zabezpieczeniami. Użytkownik nie ma dostępu do infrastruktury technicznej.
- XaaS (Anything as a Service) – model hybrydowy obejmujący różne kombinacje powyższych form usług.
Komentowany przepis opiera się na dychotomii pomiędzy modelem IaaS a pozostałymi modelami (PaaS, SaaS, XaaS). Najszersze obowiązki techniczne spoczywają na dostawcach IaaS, a w przypadku pozostałych modeli – obowiązki są węższe i sprowadzają się do zapewnienia interoperacyjności oraz usuwania przeszkód w migracji danych.
2. Obowiązki dostawców usług w modelu IaaS
Zgodnie z art. 23 lit. d Data Act, dostawcy usług przetwarzania danych nie mogą stawiać przeszkód, które utrudniają klientom uzyskanie równoważności funkcjonalnej w korzystaniu z nowej usługi przetwarzania danych u innego dostawcy, jeśli jest to usługa tego samego typu.
W modelu IaaS obowiązek ten idzie dalej: dostawcy muszą podejmować wszelkie uzasadnione środki, aby ułatwić klientowi osiągnięcie równoważności funkcjonalnej.
Co oznacza równoważność funkcjonalna?
Zgodnie z art. 2 pkt 37 DA,
„równoważność funkcjonalna oznacza przywrócenie minimalnego poziomu funkcjonalności danej usługi w środowisku nowej usługi przetwarzania danych po zmianie dostawcy. Usługa docelowa daje porównywalny rezultat w reakcji na te same dane wejściowe w sytuacji, gdy cechy dostarczane zgodnie z umową są wspólne.”
W praktyce oznacza to, że po przeniesieniu danych, aplikacji i konfiguracji do nowego dostawcy, klient powinien móc nadal korzystać z usług o porównywalnej funkcjonalności, choć niekoniecznie identycznej wydajności, jakości czy interfejsu.
Co istotne, osiągnięcie równoważności funkcjonalnej dotyczy wyłącznie usług tego samego typu – czyli takich, które mają ten sam główny cel, bazują na tym samym modelu usługi i mają kluczowe wspólne funkcje, choć mogą różnić się poziomem bezpieczeństwa, odporności czy jakości (art. 2 pkt 9 DA, motyw 81 preambuły DA).
Zakres obowiązku „ułatwienia” zmiany dostawcy
W przypadku modelu IaaS dostawca nie ma gwarantować sukcesu migracji, ale musi aktywnie współdziałać i ułatwiaćproces przeniesienia danych i funkcjonalności.
Efekt końcowy zależy od współpracy obu stron – dotychczasowego i nowego dostawcy – zgodnie z zasadą współpracy w dobrej wierze określoną w art. 27 DA.
Dostawca wyjściowy (dotychczasowy) jest zobowiązany do:
- Zapewnienia zasobów – takich jak odpowiednia moc obliczeniowa, dostęp do danych i środowiska eksportowego.
- Przekazania odpowiednich informacji – technicznych i organizacyjnych, potrzebnych do migracji.
- Udostępnienia dokumentacji – opisów interfejsów, formatów danych, konfiguracji systemu.
- Udzielenia wsparcia technicznego – np. konsultacji, pomocy przy konwersji danych.
- Zapewnienia niezbędnych narzędzi, jeśli są wymagane do eksportu lub integracji.
📄 Przykład praktyczny:
Spółka CloudLab Sp. z o.o. korzysta z infrastruktury IaaS dostarczanej przez NetSky Europe, ale planuje przenieść swoje środowisko do innego operatora – InfraHost Polska.
Dotychczasowy dostawca ma obowiązek przekazać klientowi pełną dokumentację infrastruktury, udostępnić dane eksportowalne w odpowiednim formacie i umożliwić migrację maszyn wirtualnych. Nie musi jednak gwarantować identycznego działania aplikacji – jego obowiązek ogranicza się do ułatwienia równoważności funkcjonalnej.
Znaczenie praktyczne dla dostawców IaaS
Dla dostawców modelu IaaS oznacza to konieczność:
- opracowania wewnętrznych procedur migracji danych,
- prowadzenia aktualnej dokumentacji technicznej,
- przygotowania interfejsów eksportowych i narzędzi wspierających migrację,
- szkolenia personelu w zakresie realizacji obowiązku współpracy przy zmianie dostawcy.
3. Obowiązki dostawców usług w modelach innych niż IaaS
W odróżnieniu od modelu IaaS, w przypadku którego dostawca ma obowiązek ułatwiania osiągnięcia równoważności funkcjonalnej, dostawcy usług świadczonych w innych modelach – przede wszystkim PaaS (Platform as a Service) oraz SaaS (Software as a Service) – mają obowiązek usuwania przeszkód utrudniających klientom zmianę dostawcy.
Zgodnie z art. 30 ust. 2–5 Data Act, na tych dostawców nałożono dwa kluczowe obowiązki techniczne:
- Udostępnianie otwartych interfejsów swoim klientom i nowym dostawcom usług przetwarzania danych tego samego typu.
- Zapewnianie zgodności ze wspólnymi specyfikacjami interoperacyjności, które mogą być określone przez Komisję Europejską.
3.1. Otwarte interfejsy – obowiązek udostępniania
Dostawcy usług PaaS i SaaS są zobowiązani do nieodpłatnego udostępnienia tzw. otwartych interfejsów (ang. open interfaces) swoim klientom oraz zainteresowanym docelowym dostawcom, ale nie publicznie.
Udostępnienie odbywa się wyłącznie między wskazanymi stronami procesu migracji, czyli między klientem a potencjalnym nowym dostawcą.
Otwarte interfejsy mają umożliwić opracowanie oprogramowania służącego:
- komunikacji pomiędzy różnymi usługami przetwarzania danych,
- migracji danych między środowiskami różnych dostawców,
- zachowaniu interoperacyjności pomiędzy usługami chmurowymi.
Interfejsy te powinny zawierać tyle informacji o usłudze, by możliwe było przygotowanie kompatybilnego oprogramowania – np. poprzez udostępnienie opisu API, formatów danych, schematów połączeń i parametrów konfiguracji.
📚 Przykład praktyczny:
Firma eLogistics24 korzysta z platformy PaaS, która umożliwia tworzenie aplikacji do zarządzania magazynem. Chcąc zmienić dostawcę, potrzebuje dostępu do interfejsów API starej platformy. Dostawca ma obowiązek nieodpłatnie udostępnić dokumentację interfejsu oraz dane niezbędne do integracji z nową usługą PaaS.
3.2. Zgodność ze wspólnymi specyfikacjami i normami interoperacyjności
Drugim obowiązkiem jest zapewnienie zgodności ze wspólnymi specyfikacjami, o których mowa w art. 30 ust. 3 Data Act.
Specyfikacje te mogą dotyczyć m.in.:
- standardów wymiany danych,
- formatów plików,
- protokołów komunikacji między usługami,
- zasad bezpieczeństwa i integralności danych.
W praktyce ich celem jest stworzenie zunifikowanego ekosystemu usług chmurowych, w którym dane mogą być przenoszone pomiędzy dostawcami bez utraty ich spójności i funkcjonalności.
Komisja Europejska może na mocy art. 30 DA nakazać stosowanie określonych norm lub wspólnych specyfikacji, jeśli zostaną one opublikowane w tzw. centralnym repozytorium norm Unii Europejskiej dotyczącym interoperacyjności usług przetwarzania danych.
Dostawcy usług przetwarzania danych muszą wówczas dostosować swoje rozwiązania techniczne do tych specyfikacji, przy czym:
- mają maksymalnie 12 miesięcy od dnia opublikowania odniesień do norm w repozytorium UE,
- muszą aktualizować własne rejestry internetowe, w których opisują formaty danych, struktury, stosowane normy oraz otwarte specyfikacje.
⚠️ Ważne: Obowiązek stosowania wspólnych specyfikacji nie może negatywnie wpływać na bezpieczeństwo lub integralność danych. Dostawca musi zatem pogodzić interoperacyjność z ochroną danych i ciągłością usług.
3.3. Brak wspólnych specyfikacji – prawo klienta do eksportu danych
W art. 30 ust. 5 Data Act przewidziano sytuację, w której nie istnieją jeszcze wspólne specyfikacje lub normy interoperacyjności dla danej kategorii usług chmurowych.
W takim przypadku klient zachowuje pełne prawo do żądania eksportu swoich danych.
Dostawca ma obowiązek:
- na wniosek klienta wyeksportować wszystkie dane eksportowalne,
- przekazać je w uporządkowanym, powszechnie używanym, nadającym się do odczytu maszynowego formacie.
Taki format ma umożliwiać komputerom łatwe identyfikowanie, rozpoznawanie i pozyskiwanie danych. Najczęściej oznacza to formaty takie jak JSON, XML, CSV, YAML lub inne zgodne z branżowymi standardami.
📄 Przykład praktyczny:
Spółka Medisoft Europe korzysta z systemu medycznego w modelu SaaS, który nie posiada jeszcze określonych norm interoperacyjności w repozytorium UE. Firma chce zmienić dostawcę, więc występuje z wnioskiem o eksport danych pacjentów i dokumentacji w formacie XML. Dostawca ma obowiązek spełnić żądanie w sposób umożliwiający dalsze wykorzystanie danych u nowego dostawcy usług.
3.4. Powiązanie z prawem do przenoszenia danych z RODO
Rozwiązanie z art. 30 ust. 5 DA nawiązuje do znanego z ochrony danych osobowych mechanizmu przenoszenia danych osobowych (art. 20 RODO).
W obu przypadkach chodzi o przekazanie danych w:
- ustrukturyzowanym,
- powszechnie używanym,
- nadającym się do odczytu maszynowego formacie.
Różnica polega jednak na tym, że w Data Act mowa jest nie tylko o danych osobowych, lecz również o danych nieosobowych, technicznych i biznesowych, które są przetwarzane w ramach usług chmurowych.
4. Wyłączenia przedmiotowe
Nie wszystkie usługi przetwarzania danych są objęte obowiązkami z art. 30 DA.
Zgodnie z przepisem, obowiązki ułatwiania osiągnięcia równoważności funkcjonalnej oraz zapewniania zgodności ze specyfikacjami nie mają zastosowania, jeśli:
- większość głównych cech danej usługi została opracowana na zamówienie indywidualnego klienta,
- wszystkie komponenty usługi powstały na potrzeby konkretnego klienta,
- oraz gdy usługa nie jest oferowana komercyjnie na szeroką skalę w katalogu dostawcy.
Oznacza to, że jeśli dostawca stworzył całkowicie niestandardowe, spersonalizowane rozwiązanie informatyczne (np. dedykowany system ERP dla jednej firmy), to nie musi zapewniać mechanizmów migracji i interoperacyjności przewidzianych w art. 30 DA.
📌 Przykład praktyczny:
Firma TechBuild Solutions zamówiła u dostawcy system zarządzania projektami opracowany w całości według własnej specyfikacji, z unikalnym kodem źródłowym i architekturą.
Ponieważ rozwiązanie nie jest oferowane komercyjnie innym podmiotom, dostawca nie podlega obowiązkom z art. 30 DA dotyczącym otwartych interfejsów i specyfikacji.
5. Znaczenie praktyczne art. 30 Data Act
5.1. Kluczowe obowiązki dostawców
Przepisy art. 30 DA w praktyce oznaczają, że każdy dostawca usług przetwarzania danych musi w pierwszej kolejności zidentyfikować model, w jakim świadczy swoje usługi – IaaS, PaaS, SaaS lub inny model hybrydowy (XaaS).
Od prawidłowej kwalifikacji zależy zakres obowiązków technicznych:
- dostawcy IaaS muszą aktywnie ułatwiać osiągnięcie równoważności funkcjonalnej,
- dostawcy PaaS i SaaS muszą usuwać przeszkody i zapewniać interoperacyjność za pomocą otwartych interfejsów i wspólnych specyfikacji.
Każdy dostawca, który otrzyma wniosek o zmianę usługodawcy, powinien ustalić, czy:
- zarówno jego usługa, jak i usługa docelowa są tego samego typu,
- istnieją już wspólne specyfikacje lub normy interoperacyjności opublikowane przez Komisję Europejską w centralnym repozytorium,
- w danym przypadku występuje obowiązek eksportu danych w formacie nadającym się do odczytu maszynowego.
5.2. Działania, które dostawcy powinni podjąć
Aby zapewnić zgodność z art. 30 DA, dostawcy usług chmurowych powinni opracować i wdrożyć odpowiednie polityki wewnętrzne i procedury techniczne.
W szczególności zaleca się:
- 📄 opracowanie polityki zmiany dostawcy, określającej procedurę obsługi żądań klientów o przeniesienie danych,
- 📊 prowadzenie rejestru interoperacyjności, zawierającego:
- opisy struktur i formatów danych,
- stosowane normy i otwarte specyfikacje,
- informacje o interfejsach API,
- 💻 przygotowanie narzędzi i zasobów technicznych niezbędnych do eksportu danych,
- 🧩 zapewnienie zgodności ze wspólnymi specyfikacjami w terminie 12 miesięcy od ich publikacji w repozytorium UE,
- 👥 wyznaczenie odpowiedzialnych osób w organizacji (np. specjalisty ds. interoperacyjności lub administratora migracji danych),
- 📚 szkolenie personelu z obowiązków wynikających z Data Act, w tym z art. 27 DA dotyczącego zasady współpracy w dobrej wierze.
5.3. Znaczenie dla klientów usług chmurowych
Z perspektywy przedsiębiorców korzystających z usług chmurowych przepisy art. 30 DA wprowadzają znaczącą poprawę pozycji negocjacyjnej wobec dostawców.
Przedsiębiorcy zyskują:
✔ prawo do żądania eksportu danych w ustrukturyzowanym formacie,
✔ prawo do zmiany dostawcy bez utrudnień technicznych,
✔ większą przejrzystość w zakresie interfejsów i specyfikacji,
✔ pewność ciągłości działania przy zmianie usługodawcy.
📌 Przykład praktyczny:
Spółka GreenTrade Solutions korzysta z usług PaaS, ale po wzroście cen chce przejść do innego dostawcy oferującego bardziej konkurencyjną ofertę. Na mocy art. 30 DA obecny dostawca nie może utrudniać migracji, musi udostępnić interfejsy API, a jeśli normy interoperacyjności nie zostały jeszcze opublikowane – ma obowiązek wyeksportować dane w otwartym formacie (np. JSON). Dzięki temu GreenTrade może zachować pełną funkcjonalność aplikacji po migracji.
5.4. Znaczenie dla rynku usług przetwarzania danych
Regulacja Data Act ma na celu stworzenie otwartego ekosystemu chmurowego w Unii Europejskiej, opartego na zasadach interoperacyjności, bezpieczeństwa i konkurencyjności.
Art. 30 DA ogranicza praktyki tzw. vendor lock-in i wzmacnia pozycję użytkowników danych – w tym firm, administracji publicznej i instytucji badawczych.
W dłuższej perspektywie przyczyni się to do:
- zwiększenia mobilności danych,
- rozwoju konkurencyjnych usług chmurowych,
- promowania otwartych standardów technicznych,
- ułatwienia tworzenia innowacyjnych modeli współpracy między dostawcami.
5.5. Ocena regulacji i uwagi krytyczne
Komentowany przepis został oceniony pozytywnie w doktrynie. Jego wprowadzenie stanowi ważny krok w stronę transparentności i równego dostępu do danych w środowisku cyfrowym.
Jednocześnie zwraca się uwagę na potencjalne problemy praktyczne:
⚠️ Ryzyko unikania klasyfikacji jako IaaS.
Niektórzy dostawcy mogą celowo kwalifikować swoje usługi jako PaaS lub SaaS, aby uniknąć dalej idących obowiązków związanych z ułatwianiem równoważności funkcjonalnej.
⚠️ Trudności z wdrożeniem wspólnych specyfikacji.
W początkowym okresie obowiązywania Data Act repozytorium UE może nie obejmować wszystkich typów usług chmurowych, co utrudni jednolite stosowanie przepisów.
⚠️ Koszty techniczne po stronie dostawców.
Dostosowanie infrastruktury do nowych wymogów interoperacyjności i prowadzenie aktualnych rejestrów może wymagać znacznych nakładów finansowych i zasobów kadrowych.
Pomimo tych wyzwań, regulacja zasługuje na aprobatę. Jej cele – przejrzystość, konkurencyjność i bezpieczeństwo danych – są spójne z kierunkiem rozwoju unijnego prawa cyfrowego i wspierają tworzenie jednolitego rynku danych w UE.
Podstawa prawna
- art. 2 pkt 9, art. 2 pkt 37, art. 23 lit. d, art. 27, art. 30 Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2023/2854 z dnia 13 grudnia 2023 r. w sprawie uczciwego dostępu do danych i ich wykorzystania (Data Act)
Tematy zawarte w poradniku
- zmiana dostawcy usług chmurowych Data Act
- obowiązki dostawców IaaS, PaaS i SaaS
- interoperacyjność i równoważność funkcjonalna w chmurze
- eksport danych i otwarte interfejsy API
- repozytorium norm UE i wspólne specyfikacje interoperacyjności