W Twoim regulaminie SaaS jest jedno zdanie: „Po rozwiązaniu umowy dane Klienta zostaną usunięte w terminie 30 dni”. Brzmi bezpiecznie. Od 12 września 2025 r. jest niezgodne z prawem — i jest to najmniejszy z problemów, jakie masz.
Rozdział VI rozporządzenia (UE) 2023/2854 (Data Act) narzuca dostawcom usług przetwarzania danych w chmurze i SaaS wieloetapową procedurę zmiany dostawcy. Maksymalny okres wypowiedzenia to 2 miesiące. Obowiązkowy okres przejściowy z pełną ciągłością usługi — do 30 dni. Minimum 30 dni na pobranie danych po zakończeniu migracji. Łącznie: ponad dwa miesiące po rozwiązaniu umowy, w których musisz utrzymać dostęp do danych klienta. A typowa umowa powierzenia przewiduje usunięcie danych „nie później niż w 30 dni”. Te dokumenty się wykluczają.
W tym artykule pokażę, gdzie wzorce regulaminów SaaS dostępne na rynku pękają pod Data Act, jakie terminy musisz wpisać do regulaminu i dlaczego największe ryzyko nie siedzi w samym regulaminie, lecz na styku dokumentów — w jednym zdaniu klauzuli pierwszeństwa umowy powierzenia.
Podstawowe pojęcia, zanim przejdziemy dalej
Zanim przejdziemy do konkretów, warto uporządkować kilka terminów, które pojawiają się w rozporządzeniu i które będą wracać w całym artykule.
| Pojęcie | Co oznacza na gruncie Data Act |
|---|---|
| Usługa przetwarzania danych | Usługa chmurowa lub SaaS, w której dostawca przechowuje i przetwarza dane klienta na swojej infrastrukturze — typowy model subskrypcyjny |
| Zmiana dostawcy (switching) | Procedura, w której klient przenosi dane i zasoby cyfrowe od jednego dostawcy do innego lub do własnej infrastruktury |
| Okres przejściowy | Czas po wypowiedzeniu, w którym dostawca nadal świadczy usługę z pełną ciągłością, umożliwiając klientowi migrację |
| Dane eksportowalne | Dane wprowadzone przez klienta do aplikacji, które podlegają eksportowi — bez danych referencyjnych i wewnętrznych danych dostawcy |
| Zasoby cyfrowe (aktywa cyfrowe) | Elementy w formacie cyfrowym, w tym aplikacje, z których klient ma prawo korzystać niezależnie od umowy z danym dostawcą |
| Test nieuczciwości (art. 13) | Mechanizm oceny, czy jednostronnie narzucone postanowienie umowne rażąco odbiega od dobrej praktyki handlowej — jeśli tak, nie wiąże drugiej strony |
Dwa mechanizmy przenoszalności, które regulaminy SaaS regularnie mylą: art. 20 RODO to uprawnienie osoby fizycznej wobec administratora danych osobowych. Rozdział VI Data Act to uprawnienie klienta biznesowego wobec dostawcy usługi przetwarzania danych. Inny podmiot uprawniony, inna podstawa, inne obowiązki dostawcy. Jeśli Twój regulamin ma jedną klauzulę „o przenoszeniu danych” powołującą się na oba przepisy łącznie — masz wadliwą konstrukcję.
Oś czasu procedury zmiany dostawcy według Data Act
Dostępne na rynku wzorce regulaminów SaaS albo nie mają warstwy Data Act wcale, albo mają jedno zdanie o eksporcie w formacie nadającym się do odczytu maszynowego. To nie pokrywa nawet połowy wymagań art. 25.
Poniżej pełna oś czasu, którą Twój regulamin musi odwzorowywać od 12 września 2025 r.:
| Etap | Termin | Co się dzieje |
|---|---|---|
| Wniosek klienta | Dzień 0 | Klient składa wniosek o zmianę dostawcy w formie dokumentowej. Wniosek powinien wskazywać cel: migracja do innego dostawcy, przeniesienie do własnej infrastruktury lub samo usunięcie danych |
| Okres wypowiedzenia | Maks. 2 miesiące | Klient może wskazać krótszy. Umowa nadal obowiązuje na dotychczasowych zasadach |
| Okres przejściowy | Maks. 30 dni kalendarzowych | Dostawca zapewnia pełną ciągłość usługi, udziela pomocy w migracji, informuje o znanych zagrożeniach dla ciągłości. Klient ma prawo do jednokrotnego przedłużenia o okres, który uzna za właściwszy |
| Klauzula technicznej niewykonalności | 14 dni roboczych na zawiadomienie + zastępczy okres do 7 miesięcy | Jeśli 30-dniowy okres przejściowy jest technicznie niewykonalny, dostawca musi zawiadomić klienta w 14 dni roboczych i zaproponować alternatywę |
| Okres pobrania danych | Min. 30 dni po zakończeniu migracji | Usługa nie jest już świadczona, ale dostawca zapewnia dostępność i bezpieczeństwo danych eksportowalnych |
| Zawiadomienie przed usunięciem | Min. 7 dni (konstrukcja umowna) | Dostawca informuje klienta o zamiarze usunięcia danych |
| Rozwiązanie umowy | Po zakończeniu procedury | Umowa zostaje uznana za rozwiązaną; dostawca informuje klienta |
Zwróć uwagę na arytmetykę: nawet w najkrótszym wariancie (klient wskazuje krótszy okres wypowiedzenia + 30 dni okresu przejściowego + 30 dni na pobranie danych) procedura trwa znacznie dłużej niż 30 dni, które wpisujesz w umowę powierzenia jako termin usunięcia danych.
Kto to musi wdrożyć? Każdy dostawca SaaS i usług chmurowych działający w modelu B2B, który oferuje produkt komercyjnie przez katalog usług. Wyjątek z art. 31 dotyczy wyłącznie wersji nieprodukcyjnych udostępnianych do testowania na ograniczony czas. Jeżeli w Twoim trialu klient wprowadza dane rzeczywiste — wyjątek nie działa i procedura obejmuje też umowę nieodpłatną.
Motyw 98 Data Act zwalnia z niektórych obowiązków usługi opracowane na zamówienie dla indywidualnego klienta. Ale typowy produkt SaaS sprzedawany przez stronę internetową nie kwalifikuje się do tego wyjątku.
Pięć miejsc, w których wzorce regulaminów SaaS pękają pod Data Act
1. Jedno zdanie o usunięciu danych zamiast procedury zmiany dostawcy
Typowy regulamin SaaS: „Po rozwiązaniu umowy dane Klienta zostaną usunięte w terminie 30 dni”. Art. 25 ust. 2 Data Act wymaga wieloetapowej procedury z konkretnymi terminami, obowiązkami informacyjnymi i prawem klienta do przedłużenia okresu przejściowego. Jedno zdanie o usunięciu nie spełnia żadnego z tych wymagań.
2. Brak katalogu danych eksportowalnych i katalogu wyłączeń
Bez katalogu klient może żądać eksportu licencjonowanych danych referencyjnych dostawcy — list sankcyjnych, rejestrów, słowników. Określ, co podlega eksportowi (dane wprowadzone przez klienta), w jakich formatach (XLSX/CSV, JSON dla API, PDF dla raportów), i co jest wyłączone (dane wewnętrzne aplikacji, bazy referencyjne, na które dostawca ma licencję).
3. Brak warstwy informacyjnej poza regulaminem
Art. 24 i 26 Data Act wymagają publicznego udostępnienia informacji, których nie da się zamknąć w regulaminie: rejestr struktur i formatów danych eksportowalnych, opis procedur i znanych ograniczeń technicznych migracji, informacja o jurysdykcji infrastruktury IT i środkach zapobiegających dostępowi organów państw trzecich do danych nieosobowych przechowywanych w UE. To osobna strona lub dokument, do którego regulamin odsyła.
4. Okres próbny bez procedury zmiany dostawcy
Jeżeli klient w trialu wprowadza dane rzeczywiste, wyjątek z art. 31 nie działa. A dane z trialu nie istnieją ani w umowie powierzenia, ani w polityce prywatności — zostają bez określonego terminu usunięcia. Rozciągnij procedurę na umowę nieodpłatną z odrębnymi, krótszymi terminami.
5. Brak reguły na niekompletny wniosek
Klient składa wniosek o zmianę dostawcy, ale nie wskazuje celu migracji. Bez reguły na braki wniosku niekompletne zgłoszenie blokuje bieg wszystkich terminów — dostawca nie wie, czy ma eksportować, czy usuwać. Wpisz domniemanie: jeśli klient nie wskaże celu w X dni, wniosek traktuje się jako żądanie usunięcia danych.
Klauzula pierwszeństwa umowy powierzenia — cichy wyłom w całej procedurze
To jest miejsce, w którym regulaminy SaaS mają największą wadę, o której ich autorzy nie wiedzą.
Typowa umowa powierzenia danych osobowych zawiera klauzulę: „W przypadku sprzeczności między niniejszą umową a regulaminem, w zakresie dotyczącym przetwarzania danych osobowych pierwszeństwo ma umowa powierzenia”.
Brzmi rozsądnie. Problem w tym, że w narzędziu SaaS przetwarzającym niemal wyłącznie dane osobowe (a tak jest w większości produktów B2B — od CRM przez HR po AML/KYC) ta klauzula robi trzy rzeczy naraz:
| Co robi klauzula pierwszeństwa | Skutek |
|---|---|
| Zastępuje procedurę Data Act z regulaminu 30-dniowym terminem usunięcia z umowy powierzenia | Cała wieloetapowa procedura zmiany dostawcy jest martwa — w sporze wygrywa krótszy termin z umowy powierzenia |
| Wyprowadza roszczenia poza limit kwotowy odpowiedzialności | Regulamin ma limit kwotowy. Umowa powierzenia zwykle limitu kwotowego nie zawiera. Klauzula pierwszeństwa powoduje, że wszystkie roszczenia dotyczące danych osobowych wypadają poza limit |
| Tworzy dwa sprzeczne reżimy audytu | Regulamin: audyt raz na 12 miesięcy, na koszt klienta, z 30-dniowym uprzedzeniem. Umowa powierzenia: prawo kontroli w każdym czasie, bezpłatnie w razie nakazu organu nadzorczego |
Co z tym zrobić? Masz dwie opcje:
- Zawęź klauzulę pierwszeństwa do kwestii merytorycznych przetwarzania (cele, zakres, kategorie danych) z wyraźnym wyłączeniem odpowiedzialności odszkodowawczej i terminów zakończenia usługi
- Zestrój oba dokumenty co do liczby dni i wprost odeślij z umowy powierzenia do paragrafu Data Act w regulaminie
Żadna z tych opcji nie jest trudna. Ale żadna nie zrobi się sama.
Opłaty za zmianę dostawcy — harmonogram znoszenia
Harmonogram znoszenia opłat za switching wpływa bezpośrednio na model biznesowy dostawcy SaaS:
| Okres | Zasada |
|---|---|
| 12.09.2025 – 12.01.2027 | Dostawca może pobierać obniżone opłaty za zmianę dostawcy, ale nie mogą one przekraczać kosztów faktycznie poniesionych przez dostawcę |
| Od 12.01.2027 | Pełny zakaz pobierania jakichkolwiek opłat za procedurę zmiany dostawcy. Bezpłatność obejmuje też narzędzia migracyjne i testowe |
| Multi-cloud (egress) | Opłaty za wychodzący ruch danych przy równoległym korzystaniu z usług dwóch dostawców pozostają dopuszczalne — do wysokości rzeczywiście poniesionych kosztów |
To oznacza, że od stycznia 2027 r. dostawca nie może przerzucić na odchodzącego klienta żadnej części kosztów migracji. Funkcja eksportu, utrzymanie środowiska przez okres przejściowy, narzędzia do testowania u nowego dostawcy — to wszystko po stronie dostawcy.
Test nieuczciwości z art. 13 — dlaczego Twoje ograniczenie odpowiedzialności może nie zadziałać
Art. 13 Data Act wprowadza test nieuczciwości warunków umownych między przedsiębiorcami. Nie chodzi o relację z konsumentem — chodzi o B2B.
Mechanizm działa tak:
- Warunek narzucony jednostronnie (a regulamin SaaS jest z definicji narzucony jednostronnie) podlega ocenie
- Jeśli rażąco odbiega od dobrej praktyki handlowej i jest sprzeczny z zasadą dobrej wiary — nie wiąże drugiej strony
- Ciężar dowodu, że warunek nie był jednostronnie narzucony, spoczywa na dostawcy
Art. 13 ust. 4 zawiera katalog postanowień zawsze nieuczciwych. Wśród nich: wyłączenie lub ograniczenie odpowiedzialności strony narzucającej warunek za działanie umyślne lub rażące niedbalstwo.
To ma bezpośrednie przełożenie na klauzulę ograniczenia odpowiedzialności w regulaminie SaaS. Standardowe zdanie „odpowiedzialność dostawcy ograniczona jest do kwoty X” może okazać się bezskuteczne w zakresie, w jakim obejmuje szkodę wyrządzoną umyślnie lub wskutek rażącego niedbalstwa.
Stąd rekomendacja: dwutorowe ograniczenie odpowiedzialności — ogólnie do winy umyślnej, a w zakresie związanym z udostępnianiem danych również do rażącego niedbalstwa. To spójne zarówno z art. 13 Data Act, jak i z art. 473 § 2 Kodeksu cywilnego, który zabrania wyłączenia odpowiedzialności za szkodę wyrządzoną umyślnie.
Na dziś brak orzecznictwa sądów polskich ani decyzji Prezesa UOKiK stosujących art. 13 Data Act do konkretnego postanowienia umownego. Ale brak orzecznictwa nie oznacza braku ryzyka — oznacza brak przewidywalności.
Gdzie dokumenty SaaS mówią co innego niż system
Najpoważniejsze wady regulaminu SaaS nie siedzą w samym regulaminie. Siedzą na stykach dokumentów — tam, gdzie załącznik bezpieczeństwa obiecuje coś, czego system nie robi.
| Deklaracja w dokumentach | Stan faktyczny | Ryzyko |
|---|---|---|
| „Centralne logowanie zdarzeń i rejestrowanie każdego dostępu do baz danych” | System przechowuje wyłącznie znaczniki czasowe utworzenia i modyfikacji rekordów, bez dziennika aktywności użytkowników | Brak logów uniemożliwia ustalenie zakresu incydentu — UODO w decyzji ZSOŚS.421.25.2019 wskazał brak identyfikowalności jako zagrożenie bezpieczeństwa i nałożył karę 50 000 zł |
| „Centralne zarządzanie tożsamością, w tym obsługa SSO i MFA” | MFA nie jest włączone dla użytkowników aplikacji — opis dotyczy możliwości, nie wdrożonego zabezpieczenia | Czytelnik dokumentu odczytuje to jako deklarację wdrożenia |
| „Parametry RPO/RTO zgodne z umownym SLA” | Regulamin żadnych parametrów RPO/RTO nie zawiera | Odesłanie w próżnię |
| „Trwałe usunięcie danych na żądanie” | Aplikacja oznacza rekordy jako usunięte (usunięcie logiczne), proces trwałego czyszczenia bazy nie istnieje | Obietnica trwałego usunięcia i deklaracja obsługi żądań z art. 17 RODO są nieprawdziwe |
| „Dane w kopiach zapasowych usuwane zgodnie ze standardowym cyklem retencji” | Cykl retencji nie jest określony | Otwarty okres przechowywania — naruszenie art. 5 ust. 1 lit. e RODO (ograniczenie przechowywania) |
Każde z tych pytań zadajesz wykonawcy aplikacji przed podpisaniem dokumentów. Nie po.
SLA — trzy pułapki, które zmieniają poziom usługi
Godziny wsparcia vs. całodobowo
SLA na poziomie 98% liczone wyłącznie w godzinach 8–18 w dni robocze to zupełnie inny poziom usługi niż ten sam wskaźnik liczony całodobowo. Awaria nocna i weekendowa nie obniża wskaźnika w ogóle. Zdecyduj, jak liczyć, i domknij arytmetykę jednym zdaniem: okresy wyłączone z czasu niedostępności nie pomniejszają łącznej liczby godzin stanowiącej podstawę obliczenia wskaźnika.
Dla porównania — dokumentacja Microsoft Power Platform podaje, że 99,9% dostępności odpowiada ok. 43 minutom niedostępności miesięcznie, a 99,95% — ok. 21 minutom. Ale te wartości mają sens tylko przy jasnej definicji niedostępności i sposobu pomiaru.
Definicja niedostępności bez wyłączeń
Jeśli nie zdefiniujesz niedostępności negatywnie (czym niedostępność nie jest), to spadek wydajności, wydłużenie czasu przetwarzania, błąd pojedynczej funkcjonalności — a nawet nieprawidłowy wynik generowany przez model AI — stają się naruszeniem SLA. Halucynacja modelu staje się podstawą kredytu serwisowego. Wyłącz to wprost.
Kredyt serwisowy po rozwiązaniu umowy
Niedostępność wystąpiła w ostatnim miesiącu umowy. Nie ma kolejnego okresu rozliczeniowego, od którego można udzielić upustu. Kredyt serwisowy — formalnie wyłączny środek klienta — nie działa. Dopisz mechanizm: obniżenie opłaty za ostatni okres rozliczeniowy albo zwrot jej części w 14 dni od uznania wniosku.
Warstwa AML i AI — dodatkowe obowiązki, o których regulamin milczy
Narzędzie SaaS nie jest archiwum
Jeśli budujesz narzędzie, w którym instytucja obowiązana (bank, fintech, biuro rachunkowe, pośrednik nieruchomości) weryfikuje kontrahentów na potrzeby AML — pamiętaj o art. 49 ustawy AML. Instytucja obowiązana ma 5-letni obowiązek przechowywania dokumentacji. Ten obowiązek zostaje po stronie klienta, nie dostawcy narzędzia.
Ale klient zakłada, że dokumentacja wykonania jego obowiązków ustawowych leży bezpiecznie w aplikacji. Dostawca zakłada, że klient pobiera ją na bieżąco. Ten rozjazd wychodzi przy kontroli organu albo przy zamknięciu konta — w najgorszym momencie.
Co wpisać do regulaminu: trzy zdania na początku, które określają charakter aplikacji — narzędzie operacyjne, nie archiwum. Obowiązek bieżącego pobierania wyników przez klienta. Zastrzeżenie, że kopie zapasowe nie są usługą archiwizacji. Te trzy zdania robią w sporze więcej niż cała klauzula ograniczenia odpowiedzialności, bo usuwają źródło roszczenia zamiast je limitować.
Dostawcy modeli językowych klasyfikują Twoje zapytania
Jeśli Twój produkt SaaS korzysta z modelu językowego (LLM), sprawdź warunki dostawcy. OpenAI domyślnie przechowuje dane z API do 30 dni w celu wykrywania nadużyć. Treść oznaczona jako podejrzana może być poddana przeglądowi przez upoważniony personel. Wyłączenie tej funkcji (zero data retention) bywa dostępne tylko dla klientów o określonym statusie umownym.
To przetwarzanie danych osobowych, jeżeli prompty zawierają takie dane — a w narzędziu AML/KYC zawierają je prawie zawsze. Zdecyduj, w którym dokumencie to ujawnić: wykaz podprocesorów, umowa powierzenia, klauzula poufności.
AI Act — termin do zapamiętania
Obowiązki AI Act dla systemów wysokiego ryzyka z załącznika III oraz obowiązki przejrzystości z art. 50 stosują się od 2 sierpnia 2026 r. Scoring ryzyka kontrahenta będącego osobą prawną co do zasady nie mieści się literalnie w załączniku III pkt 5 lit. b (który dotyczy oceny zdolności kredytowej osób fizycznych). Ale jeśli Twoje narzędzie ocenia osoby fizyczne i wynik materialnie wpływa na decyzję finansową — kwalifikacja jako system wysokiego ryzyka jest uzasadniona. Pełny tekst AI Act wymaga, by ocena braku kwalifikacji była udokumentowana, a nie zadeklarowana.
Zarządzanie dostępami — termin, który nie przejdzie kontroli
Termin „niezwłocznie, nie później niż w terminie 21 dni” na odebranie dostępu byłemu pracownikowi klienta jest w narzędziu przetwarzającym dane o podejrzeniach przestępstwa nie do obrony na gruncie art. 32 RODO.
Wybierz jeden model zarządzania dostępami i skróć termin:
| Model | Jak działa | Termin odebrania dostępu |
|---|---|---|
| Administrator klienta | Klient sam zarządza kontami użytkowników w panelu administracyjnym | Natychmiast — odpowiedzialność po stronie klienta |
| Obsługa przez dostawcę | Klient zgłasza żądanie, dostawca wykonuje | Godziny lub dni robocze — nie tygodnie |
Oddziel termin odebrania dostępu byłemu użytkownikowi od terminu blokady konta po rozwiązaniu umowy. To dwie różne sytuacje z różnym poziomem ryzyka.
Sankcje — co wiemy, a czego jeszcze nie wiemy
Art. 37 ust. 1 Data Act nakłada na każde państwo członkowskie obowiązek wyznaczenia co najmniej jednego organu właściwego. Projekt polskiej ustawy wdrażającej (druk sejmowy nr 3266) przewiduje wyznaczenie Prezesa UKE jako głównego organu oraz wprowadzenie administracyjnych kar pieniężnych.
Na dzień publikacji tego artykułu nie potwierdzono uchwalenia polskiej ustawy wdrażającej. Oznacza to, że:
- Brak krajowego organu egzekwującego rozdział VI Data Act
- Brak krajowego katalogu sankcji
- Samo rozporządzenie stosuje się bezpośrednio — obowiązki dostawców obowiązują niezależnie od stanu ustawy krajowej
Brak sankcji krajowych nie oznacza braku ryzyka. Nieuczciwy warunek umowny w rozumieniu art. 13 Data Act nie wiąże drugiej strony — ryzyko, że cała klauzula ograniczenia odpowiedzialności okaże się bezskuteczna w sporze, istnieje niezależnie od tego, czy organ nałoży karę.
Skala problemu — ponad połowa firm w UE korzysta z SaaS
Według danych Eurostatu za 2025 r., 52,74% przedsiębiorstw w UE korzystało z płatnych usług chmurowych. Spośród nich 96,44% nabywało co najmniej jedną usługę SaaS. To oznacza, że obowiązki z rozdziału VI Data Act dotyczą dostawców obsługujących zdecydowaną większość europejskiego rynku B2B.
Komisja Europejska opracowała niewiążące standardowe klauzule umowne (SCC) dla umów chmurowych, obejmujące trzy grupy: SCC Switching & Exit, SCC Termination oraz SCC Security & Business Continuity. Mogą służyć jako punkt wyjścia przy redagowaniu klauzul regulaminowych, ale nie zastępują obowiązków wynikających z rozporządzenia.
Checklist — dwanaście pytań do Twojego regulaminu SaaS
Zanim wyślesz pakiet dokumentów do klienta, przejdź przez tę listę:
| Nr | Pytanie | Gdzie szukać odpowiedzi |
|---|---|---|
| 1 | Czy regulamin zawiera osobny paragraf o zmianie dostawcy z pełną osią czasu (wniosek → wypowiedzenie → okres przejściowy → pobranie danych → usunięcie)? | Regulamin — sekcja o rozwiązaniu umowy |
| 2 | Czy umowa powierzenia i regulamin mają spójne terminy usunięcia danych? | Porównanie obu dokumentów |
| 3 | Czy klauzula pierwszeństwa umowy powierzenia jest zawężona do kwestii merytorycznych przetwarzania? | Umowa powierzenia — postanowienia końcowe |
| 4 | Czy istnieje katalog danych eksportowalnych i katalog wyłączeń? | Załącznik do regulaminu |
| 5 | Czy informacje o formatach, strukturach i jurysdykcji infrastruktury są publicznie dostępne? | Strona internetowa dostawcy |
| 6 | Czy okres próbny jest objęty procedurą zmiany dostawcy i umową powierzenia? | Regulamin + umowa powierzenia |
| 7 | Czy SLA definiuje niedostępność pozytywnie i negatywnie (w tym wyłączenie nieprawidłowości AI)? | Załącznik SLA |
| 8 | Czy kredyt serwisowy działa po rozwiązaniu umowy? | Załącznik SLA |
| 9 | Czy termin odebrania dostępu byłemu użytkownikowi jest liczony w godzinach/dniach, nie w tygodniach? | Regulamin lub załącznik bezpieczeństwa |
| 10 | Czy deklaracje bezpieczeństwa (logi, MFA, RPO/RTO, retencja kopii, usuwanie) odpowiadają rzeczywistej architekturze systemu? | Porównanie załącznika bezpieczeństwa z dokumentacją techniczną |
| 11 | Czy regulamin określa charakter aplikacji (narzędzie operacyjne vs. archiwum)? | Regulamin — postanowienia ogólne |
| 12 | Czy dostawca modelu językowego jest ujawniony w wykazie podprocesorów z informacją o retencji promptów? | Wykaz podprocesorów |
Jak możemy pomóc Twojej firmie uporządkować dokumenty SaaS
Dostosowanie regulaminu SaaS do Data Act to nie korekta kilku zdań. To zmiana, która wymaga zestawienia dokumentów z architekturą produktu — i podjęcia decyzji, które wykraczają poza sam tekst umowy.
Wspieramy dostawców SaaS i firm technologicznych w trzech wariantach:
- Audyt zgodności — przegląd regulaminu pod kątem rozdziału VI Data Act, zestawienie z umową powierzenia, lista rozjazdów do naprawy
- Przepisanie warstwy umownej — paragraf o zmianie dostawcy, katalog danych eksportowalnych, SLA, mapa ról przy danych osobowych, zestrojenie regulaminu z umową powierzenia
- Pełny pakiet dokumentów — cały zestaw napisany od zera wraz z warstwą informacyjną publikowaną poza umową, listą pytań do wykonawcy aplikacji i kontrolą spójności przed wysłaniem do klientów
Łączymy prawo IT, ochronę danych i prawo umów w jednym modelu — zamiast rozbijać pracę na osobne obszary. Pracujemy na rzeczywistych scenariuszach: jak wygląda eksport danych w Twoim produkcie, co robi Twój model AI z promptami, gdzie leżą kopie zapasowe i kto za nie odpowiada.
Regulamin SaaS po Data Act — trzy rzeczy do zrobienia w tym tygodniu
Rozdział VI Data Act stosuje się od 12 września 2025 r. Twój regulamin SaaS niemal pewnie go nie spełnia — i problem nie leży w jednym zdaniu o usunięciu danych, lecz w całej konstrukcji wyjścia z umowy, na stykach dokumentów i w rozjazdach między deklaracjami a architekturą systemu.
Trzy rzeczy do zrobienia teraz:
- Otwórz swój regulamin i wyszukaj fragment o skutkach rozwiązania umowy. Jeśli to jedno zdanie — masz niezgodność
- Porównaj termin usunięcia danych w umowie powierzenia z osią czasu procedury zmiany dostawcy w regulaminie. Jeśli się wykluczają — klauzula pierwszeństwa umowy powierzenia wyzeruje Ci całą procedurę
- Zapytaj wykonawcę aplikacji, czy system robi to, co obiecują załączniki bezpieczeństwa — logi, MFA, trwałe usuwanie, cykl retencji kopii
Jeśli potrzebujesz wsparcia w przeglądzie dokumentów, przepisaniu procedury zmiany dostawcy lub zestawieniu regulaminu z rzeczywistą architekturą produktu — napisz do nas.
Najczęściej zadawane pytania
Czy Data Act dotyczy mnie, jeżeli jestem małym dostawcą SaaS, a nie hyperscalerem? Tak. Rozdział VI Data Act stosuje się do dostawców usług przetwarzania danych niezależnie od ich wielkości, jeśli oferują usługę komercyjnie. Wyjątek z motywu 98 dotyczy wyłącznie usług opracowanych na zamówienie dla indywidualnego klienta — typowy produkt SaaS sprzedawany przez katalog się w nim nie mieści.
Mój regulamin SaaS powstał dwa lata temu — od czego zacząć, żeby sprawdzić, czy jest zgodny z Data Act? Otwórz sekcję o rozwiązaniu umowy i sprawdź, czy zawiera osobny paragraf o zmianie dostawcy z pełną osią czasu: wniosek klienta, okres wypowiedzenia (maks. 2 miesiące), okres przejściowy (maks. 30 dni), okres pobrania danych (min. 30 dni), zawiadomienie przed usunięciem. Jeśli masz jedno zdanie o usunięciu danych w 30 dni — masz niezgodność. Następnie porównaj ten termin z terminem w umowie powierzenia i sprawdź klauzulę pierwszeństwa.
Czy muszę udostępnić klientowi eksport bezpłatnie już teraz, czy dopiero od stycznia 2027 r.? Do 12 stycznia 2027 r. możesz pobierać obniżone opłaty za zmianę dostawcy, ale nie mogą one przekraczać kosztów faktycznie poniesionych. Od 12 stycznia 2027 r. obowiązuje pełny zakaz opłat za procedurę zmiany dostawcy — w tym za narzędzia migracyjne i testowe. Opłaty za egress w modelu multi-cloud pozostają dopuszczalne do wysokości kosztów.
Mój trial jest darmowy — czy procedura zmiany dostawcy mnie dotyczy? Jeżeli w trialu klient wprowadza dane rzeczywiste, wyjątek z art. 31 Data Act (dotyczący wersji nieprodukcyjnych udostępnianych do testowania na ograniczony czas) nie działa. Procedura zmiany dostawcy obejmuje też umowę nieodpłatną. Wprowadź pojęcie okresu próbnego do umowy powierzenia i polityki prywatności z odrębnymi, krótszymi terminami.
Jak długo muszę trzymać dane klienta po rozwiązaniu umowy? Według osi czasu Data Act: przez okres przejściowy (maks. 30 dni z ciągłością usługi) plus minimum 30 dni na pobranie danych po zakończeniu migracji. Łącznie — znacznie dłużej niż 30 dni, które wpisujesz w umowę powierzenia. Jeśli Twój klient jest instytucją obowiązaną na gruncie ustawy AML, pamiętaj, że 5-letni obowiązek przechowywania dokumentacji z art. 49 ustawy AML pozostaje po stronie klienta — Twoja aplikacja nie przenosi tego obowiązku na Ciebie.
Dlaczego standardowe zdanie o pierwszeństwie umowy powierzenia jest ryzykowne? Ponieważ w narzędziu SaaS przetwarzającym głównie dane osobowe klauzula pierwszeństwa wyprowadza niemal wszystkie roszczenia poza limit kwotowy odpowiedzialności z regulaminu (umowa powierzenia zwykle limitu kwotowego nie zawiera) i zastępuje wieloetapową procedurę Data Act krótszym terminem usunięcia danych z załącznika do umowy powierzenia. Zawęź klauzulę do kwestii merytorycznych przetwarzania albo zestrój terminy w obu dokumentach.
