Polska chmura vs hyperscaler – suwerenność danych i Cloud Act w praktyce

W skrócie: Suwerenność danych to kontrola nad tym, czyjej jurysdykcji podlegają Państwa dane – a nie tylko to, w którym kraju stoją serwery. Amerykański CLOUD Act i FISA 702 mogą sięgać danych przetwarzanych przez AWS, Azure i Google Cloud nawet w regionach UE, bo spółki matki podlegają prawu USA. Polska chmura eliminuje ten wektor ryzyka i daje przewidywalne koszty (brak egress). Hyperscaler bywa właściwym wyborem – ten przewodnik pokazuje, kiedy który.
Wybór między polską chmurą a hyperscalerem (AWS, Microsoft Azure, Google Cloud) coraz rzadziej sprowadza się do samej technologii – infrastrukturalnie różnice się zacierają. Realna decyzja dotyczy trzech warstw ryzyka: jurysdykcji (czyje prawo może sięgnąć danych), zgodności (RODO, NIS2, DORA) oraz ekonomii (przewidywalność rachunku). W tym materiale rozkładamy każdą z nich na czynniki pierwsze i pokazujemy, które dane warto trzymać w Polsce, a które spokojnie mogą zostać u globalnego dostawcy.
Suwerenność danych – co to naprawdę znaczy
Suwerenność danych (data sovereignty) bywa mylona z rezydencją danych. To nie to samo.
- Rezydencja danych – fizyczna lokalizacja serwerów (np. region „Europe” w Warszawie lub Frankfurcie).
- Suwerenność danych – to, jakiemu porządkowi prawnemu podlegają dane i podmiot, który nimi rozporządza.
Różnica jest kluczowa, bo dane mogą fizycznie leżeć w Niemczech, a mimo to podlegać żądaniom organów USA – jeśli operatorem jest spółka podlegająca amerykańskiej jurysdykcji. Do tego dochodzi trzecie pojęcie – suwerenność cyfrowa (digital sovereignty) – czyli zdolność organizacji lub państwa do działania niezależnie od dostawcy: bez ryzyka, że zmiana polityki, sankcje czy decyzja korporacyjna odetną dostęp do własnej infrastruktury.
W praktyce dla decydenta IT suwerenność danych to odpowiedź na jedno pytanie: kto – poza nami – może zgodnie z prawem uzyskać dostęp do naszych danych i czy mamy nad tym kontrolę.
Dlaczego suwerenność to temat 2026
Trzy siły zbiegły się w czasie i wypchnęły temat z niszy prawniczej do sal zarządów.
1. Regulacje. NIS2 rozszerzyła obowiązki bezpieczeństwa i nadzoru nad łańcuchem dostaw ICT na tysiące polskich firm, a polska ustawa wdrażająca ją do krajowego porządku prawnego nakłada obowiązek rejestracji podmiotów kluczowych i ważnych w terminie przypadającym na początek października 2026 r. DORA, obowiązująca w sektorze finansowym od 17 stycznia 2025 r., wprost wymaga zarządzania ryzykiem dostawców zewnętrznych ICT oraz udokumentowanej strategii wyjścia, a UKNF adresuje ten obszar osobnymi komunikatami dla podmiotów nadzorowanych.
Doszły do tego dwa akty, które zmieniają praktykę bardziej, niż się o nich mówi. Data Act ogranicza opłaty za przenoszenie danych między dostawcami i od 12 stycznia 2027 r. zakazuje ich całkowicie, co realnie zmienia rachunek przy wyjściu od dostawcy. Rozporządzenie e-Evidence, stosowane od 18 sierpnia 2026 r., daje z kolei organom państw UE możliwość żądania danych bezpośrednio od dostawców w innych państwach członkowskich – i to warto powiedzieć uczciwie: dostęp organów do danych nie jest wyłącznie amerykańską specjalnością. Różnica polega na tym, w jakim porządku prawnym się odbywa, z jaką kontrolą sądową i czy przysługują nam w nim jakiekolwiek środki.
Regulator pyta już więc nie tylko „czy dane są szyfrowane”, ale „czyjej jurysdykcji podlega Wasz dostawca i co zrobicie, jeśli ta jurysdykcja się zmieni”.
2. Geopolityka. Rosnąca nieprzewidywalność relacji transatlantyckich sprawiła, że zależność krytycznych usług od jednej jurysdykcji przestała być abstrakcją. Organizacje sektora publicznego, zdrowia i infrastruktury krytycznej traktują to dziś jako element analizy ryzyka, nie polityki.
3. Koszty. Po latach migracji „do chmury za wszelką cenę” firmy policzyły rachunki. Opłaty za transfer danych (egress), nieprzewidywalne skoki kosztów i vendor lock-in uruchomiły falę repatriacji obciążeń – powrotu części workloadów do przewidywalnych, lokalnych środowisk.
Cloud Act i FISA 702 – jak prawo USA sięga danych w UE
To najczęściej mylona i najczęściej wyolbrzymiana część układanki. Trzymajmy się faktów.
CLOUD Act w jednym akapicie
CLOUD Act (Clarifying Lawful Overseas Use of Data Act) z 2018 r. znowelizował amerykański Stored Communications Act. Zasada jest prosta: dostawca usług podlegający jurysdykcji USA musi wydać dane będące w jego „posiadaniu, pieczy lub kontroli” – niezależnie od tego, gdzie na świecie te dane fizycznie się znajdują. Amerykańska spółka matka może więc zostać prawnie zobowiązana do wydania danych przechowywanych przez jej europejską spółkę zależną.
Uczciwie o zabezpieczeniach, bo one istnieją i pominięcie ich byłoby manipulacją. Żądanie nie jest wnioskiem administracyjnym: wymaga nakazu sądowego opartego na uprawdopodobnionym podejrzeniu (probable cause), a dostawca ma prawo je zakwestionować, jeśli wykonanie naruszałoby prawo państwa, w którym dane się znajdują (§ 2703(h) Stored Communications Act).
I tu jest haczyk, o którym mówi się najrzadziej. Ta ścieżka kwestionowania działa w praktyce wtedy, gdy między USA a danym państwem obowiązuje umowa wykonawcza (executive agreement). Takie umowy mają Wielka Brytania i Australia. Unia Europejska i Polska nie mają żadnej – negocjacje toczą się od 2019 roku bez rozstrzygnięcia. Polska firma, której dane znalazły się w zakresie takiego żądania, nie ma więc zbudowanej ścieżki prawnej, żeby się o tym w ogóle dowiedzieć, bo nakazom często towarzyszy zakaz informowania klienta.
FISA 702 – dlaczego dotyczy firm z UE
Sekcja 702 amerykańskiej ustawy FISA (Foreign Intelligence Surveillance Act) pozwala wywiadowi USA pozyskiwać – od dostawców usług łączności elektronicznej podlegających USA – dane osób spoza USA znajdujących się poza terytorium USA. Innymi słowy: to narzędzie wymierzone dokładnie w podmioty takie jak europejskie firmy korzystające z amerykańskiej chmury.
Sekcja 702 była przedłużana wielokrotnie, ostatnio w kwietniu 2024 r. ustawą RISAA, na dwa lata. 12 czerwca 2026 r. autoryzacja wygasła – po raz pierwszy w historii tego przepisu. Nie oznacza to jednak, że inwigilacja się skończyła: zbieranie danych trwa na podstawie certyfikacji wydanych wcześniej przez sąd FISC i pozostaje legalne mniej więcej do marca 2027 r., a w Kongresie trwają prace nad reautoryzacją.
Dla europejskiej firmy ta sytuacja jest właściwie gorsza niż stabilny przepis. Podstawa prawna, na której opiera się unijna decyzja o adekwatności i cała Państwa dokumentacja transferu, jest dziś przedmiotem sporu politycznego w obcym parlamencie – o nieznanym terminie rozstrzygnięcia i nieznanym wyniku. Model zgodności zakładający, że za rok obowiązuje to samo prawo co dziś, opiera się na założeniu, którego nikt po naszej stronie nie kontroluje.
To właśnie ten mechanizm był sednem wyroku Schrems II.
„Region UE” to nie to samo co „jurysdykcja UE”
Hyperscalerzy nie zignorowali tego problemu i warto to powiedzieć wprost. Microsoft ma EU Data Boundary, Google ma Sovereign Controls, a AWS European Sovereign Cloud od stycznia 2026 r. działa komercyjnie: jako odrębna partycja z pierwszym regionem w Brandenburgii, obsługiwana przez niemieckie spółki z niemieckim personelem i z własną strukturą zarządzania. To nie jest zapowiedź ani deklaracja intencji, tylko działający produkt – i pod względem ograniczenia dostępu do danych idzie dalej niż cokolwiek, co hyperscalerzy oferowali wcześniej.
Wektor jurysdykcyjny mimo to pozostaje, bo jego źródłem nie jest lokalizacja serwerów ani narodowość personelu, tylko struktura własności. Najlepszym dostępnym dowodem nie jest opinia konkurencji, lecz zeznanie samego dostawcy: w czerwcu 2025 r. przedstawiciele Microsoft France, pytani przed francuskim Senatem, czy mogą zagwarantować, że dane obywateli UE nigdy nie zostaną przekazane organom USA bez zgody rządu francuskiego, odpowiedzieli, że nie mogą tego zagwarantować.
To nie jest zarzut wobec hyperscalerów. To cecha strukturalna modelu własnościowego, której żadna warstwa techniczna ani umowna nie sprowadza do zera.
Polski dostawca chmury podlega wyłącznie polskiej i unijnej jurysdykcji. Nie ma amerykańskiej spółki matki, więc CLOUD Act i FISA 702 po prostu nie mają do niego zastosowania. To najczystsza forma suwerenności jurysdykcyjnej dostępna dla polskiej firmy.
RODO, Schrems II i Data Privacy Framework – gdzie realnie jest ryzyko
W 2020 r. TSUE w wyroku Schrems II (C-311/18) unieważnił Privacy Shield, wskazując na niewystarczającą ochronę danych Europejczyków przed amerykańską inwigilacją (m.in. FISA 702). W lipcu 2023 r. Komisja Europejska przyjęła nową decyzję o adekwatności – EU-US Data Privacy Framework (DPF) – która ponownie zalegalizowała transfery danych do certyfikowanych podmiotów w USA.
Co to oznacza w praktyce w 2026 r.:
- Transfery do hyperscalerów certyfikowanych w DPF są obecnie zgodne z prawem. To nie jest „szara strefa”.
- DPF przeszedł już pierwszy test sądowy i go zdał. 3 września 2025 r. Sąd Unii Europejskiej oddalił skargę francuskiego posła Philippe’a Latombe’a na decyzję o adekwatności, uznając, że skarżący nie wykazał niewystarczającego poziomu ochrony. Decyzja obowiązuje, transfery na jej podstawie są legalne i nie warto udawać, że jest inaczej.
- Sprawa nie jest jednak zamknięta. 31 października 2025 r. wniesiono odwołanie do TSUE – tego samego trybunału, który wcześniej unieważnił Safe Harbour i Privacy Shield. Komisja Europejska ma przy tym obowiązek monitorowania podstaw decyzji o adekwatności, a jedną z nich jest funkcjonowanie sekcji 702, której autoryzacja wygasła w czerwcu 2026 r.
- Wniosek dla planowania jest więc taki: dziś zgodność oparta na DPF jest w porządku, a ryzykiem nie jest złamanie prawa. Ryzykiem jest to, że w horyzoncie kilku lat prawo może się zmienić po raz trzeci – a przebudowa architektury danych pod presją terminu wyznaczonego wyrokiem kosztuje wielokrotnie więcej niż zaprojektowanie jej od razu tak, żeby problem transferu w ogóle nie powstawał.
- Nawet przy ważnym DPF administrator danych (Państwa firma) pozostaje odpowiedzialny za ocenę ryzyka transferu i – w wielu przypadkach – za środki uzupełniające (np. szyfrowanie z kluczami po stronie klienta).
Jest jeszcze jedna podstawa, o której mówi się rzadziej, a która w tym sporze jest najmocniejsza, bo pochodzi z prawa unijnego, nie z interpretacji przepisów amerykańskich. Artykuł 48 RODO stanowi wprost, że orzeczenie sądu lub decyzja organu państwa trzeciego, nakazujące przekazanie danych, mogą być wykonane tylko wtedy, gdy opierają się na umowie międzynarodowej – na przykład umowie o wzajemnej pomocy prawnej. W wytycznych 02/2024 Europejska Rada Ochrony Danych potwierdziła tę wykładnię: samo żądanie organu państwa trzeciego nie jest podstawą prawną przekazania danych w rozumieniu RODO.
Skutek praktyczny jest niekomfortowy dla wszystkich stron. Dostawca podlegający jednocześnie prawu USA i RODO może znaleźć się w sytuacji, w której wykonanie jednego obowiązku oznacza naruszenie drugiego. Państwa firma nie ma na ten konflikt żadnego wpływu, ale ponosi jego konsekwencje – bo administratorem danych pozostajecie Państwo.
Wniosek nie brzmi „hyperscaler łamie RODO”. Brzmi: zgodność oparta na DPF jest ważna, ale mniej przewidywalna w długim horyzoncie niż przetwarzanie w polskiej jurysdykcji, gdzie problem transferu w ogóle nie powstaje.
NIS2 i DORA – dlaczego regulator patrzy na dostawcę
Dla firm objętych NIS2 i DORA wybór dostawcy chmury przestał być decyzją wyłącznie IT. Oba reżimy nakładają obowiązki dotyczące ryzyka łańcucha dostaw ICT:
- NIS2 wymaga zarządzania bezpieczeństwem łańcucha dostaw i nadzoru nad dostawcami usług kluczowych dla ciągłości działania.
- DORA w sektorze finansowym wprost reguluje ryzyko dostawców zewnętrznych ICT, wymaga rejestru umów, klauzul audytowych oraz udokumentowanej strategii wyjścia od krytycznych dostawców.
Dostawca w polskiej jurysdykcji upraszcza część tych obowiązków: łatwiejszy audyt, jasne prawo właściwe umowy, brak transferu poza EOG do udokumentowania. Interpretacje konkretnych wymogów warto potwierdzić z prawnikiem lub inspektorem ochrony danych – regulacje mapuje się na organizację indywidualnie. Więcej o obowiązkach compliance piszemy w bazie wiedzy Engave o zgodności z NIS2 i DORA.
Polska chmura vs hyperscaler – tabela porównawcza
| Kryterium | Polska chmura (Engave) | Hyperscaler (AWS / Azure / GCP) |
|---|---|---|
| Jurysdykcja / Cloud Act | Wyłącznie PL/UE. CLOUD Act i FISA 702 nie mają zastosowania | Region w UE możliwy, ale spółka matka podlega prawu USA – wektor CLOUD Act pozostaje |
| Transfer danych (egress) | Brak dopłat za egress – w cenie usługi | Naliczany za każdy GB wyjścia (typowo ~0,05-0,09 USD/GB); rośnie z ruchem |
| Model cenowy | Stała, jawna cena za pojemność i maszyny | Elastyczny, ale trudny do prognozy; koszt zależy od setek pozycji |
| RODO / lokalizacja | Dane w Polsce, brak problemu transferu poza EOG | Zgodność przez DPF/SCC; wymaga oceny transferu i środków uzupełniających |
| Wsparcie | L2 24/7 w cenie, kontakt po polsku | Podstawowe w cenie; realny SLA i inżynier – w płatnych planach |
| Latencja (użytkownicy w PL) | Bardzo niska – Equinix Warszawa, zwykle poniżej kilku ms | Porównywalna przy regionie w Warszawie (Azure Poland Central, Google europe-central2); wyraźnie wyższa przy regionach zagranicznych – do Frankfurtu typowo 20-40 ms. AWS nie ma dziś regionu w Polsce |
| Skala globalna / usługi PaaS | Ukierunkowana na IaaS i chmurę prywatną | Ogromny katalog usług zarządzanych, obecność na całym świecie |
| Vendor lock-in / wyjście | Standardowe technologie, prosta repatriacja | Głęboka integracja usług autorskich utrudnia wyjście |
Uczciwie: hyperscaler wygrywa skalą globalną i bogactwem usług zarządzanych (PaaS, ML, globalny CDN). Polska chmura wygrywa jurysdykcją, przewidywalnością kosztu i wsparciem. To nie jest wybór „lepszy/gorszy”, lecz dopasowanie profilu ryzyka do obciążenia.
Egress i przewidywalność kosztów – ukryta strona rachunku
Suwerenność ma też wymiar czysto finansowy. W modelu hyperscalera płaci się nie tylko za przechowywanie i moc obliczeniową, ale za wyjście danych (egress) – transfer do internetu, do innego regionu, a czasem między strefami. Dla obciążeń intensywnie przesyłających dane (backup, hurtownie, systemy streamujące, częsta wymiana z klientami) egress potrafi urosnąć do znaczącej pozycji rachunku i – co gorsza – jest trudny do zaplanowania z góry.
Dane Engave (z projektów migracyjnych i benchmarków wewnętrznych):
- W repatriowanych do nas środowiskach opłaty za egress stanowiły średnio 12-18% miesięcznego rachunku hyperscalera przed migracją – pozycja, która w naszym modelu spada do zera.
- Po przejściu na stałą, jawną cenę klienci raportują zmienność miesięcznego rachunku poniżej 5% (wobec dwucyfrowych wahań wcześniej), co realnie upraszcza budżetowanie IT.
- Standardowy projekt lift-and-shift startuje u nas od ok. 5 000 zł, a punktem odniesienia dla latencji jest lokalizacja w Equinix Warszawa – zwykle poniżej kilku ms dla użytkowników w Polsce.
Dane oznaczone jako wewnętrzne dane Engave; wartości zależą od profilu obciążenia i mają charakter poglądowy.
Przewidywalność bywa niedoceniana, dopóki nie trzeba wytłumaczyć zarządowi, dlaczego rachunek za chmurę wzrósł o 40% w miesiącu wzmożonego ruchu.
Kiedy hyperscaler jest OK, a kiedy polska chmura wygrywa
Bez ideologii – to decyzja o dopasowaniu.
Hyperscaler bywa właściwym wyborem, gdy:
- korzystają Państwo z bogatych usług zarządzanych (PaaS, uczenie maszynowe, globalny CDN), których lokalnie nie ma;
- odbiorcy są rozproszeni globalnie i liczy się obecność w wielu regionach świata;
- dane są jawne lub niskiej wrażliwości, a egress jest niewielki;
- zespół ma dojrzałą praktykę FinOps i realnie kontroluje koszty.
Polska chmura daje przewagę, gdy:
- przetwarzają Państwo dane wrażliwe lub regulowane (zdrowie, finanse, sektor publiczny, dane osobowe na dużą skalę);
- podlegają Państwo NIS2 lub DORA i chcą uprościć audyt oraz strategię wyjścia;
- liczy się przewidywalność kosztu i brak niespodzianek za egress;
- użytkownicy są w Polsce i liczy się niska latencja oraz wsparcie po polsku;
- suwerenność jurysdykcyjna jest elementem polityki ryzyka organizacji.
Najczęściej optymalny jest model hybrydowy: dane wrażliwe i przewidywalne obciążenia w polskiej chmurze, globalne usługi zarządzane u hyperscalera. Fundamentem takiego podejścia jest dobrze zaprojektowana chmura prywatna – opisujemy ją w pillarze o chmurze prywatnej dla firm.
Które dane przenieść do polskiej chmury – checklista klasyfikacji
Zamiast migrować wszystko lub nic, warto sklasyfikować obciążenia. Praktyczna ścieżka:
1. Zinwentaryzuj dane i obciążenia – jakie zbiory przetwarzacie, gdzie stoją, kto ma dostęp.
2. Oznacz wrażliwość – dane osobowe (zwłaszcza szczególnych kategorii), tajemnica przedsiębiorstwa, dane objęte NIS2/DORA vs dane jawne.
3. Zmapuj wymogi regulacyjne – które zbiory podlegają RODO w zakresie transferu, NIS2, DORA, wymogom sektorowym.
4. Policz egress i zmienność kosztu – które obciążenia generują drogi, trudny do prognozy transfer.
5. Oceń zależność od usług autorskich – czy obciążenie jest głęboko wpięte w PaaS hyperscalera, czy przenośne.
6. Przypisz workload do modelu – wrażliwe/regulowane/kosztowo zmienne do polskiej chmury; globalne/jawne/PaaS-owe do hyperscalera.
7. Zaplanuj migrację i strategię wyjścia – kolejność, RTO/RPO, ścieżka repatriacji (wymóg DORA dla krytycznych dostawców).
Taką klasyfikację i ocenę „co przenieść” wykonujemy w ramach konsultacji suwerenności – punkt wyjścia opisujemy przy usłudze migracji (engavecloud.pl/migracja).
FAQ
Czym różni się suwerenność danych od rezydencji danych?
Rezydencja to fizyczna lokalizacja serwerów. Suwerenność to jurysdykcja – czyje prawo może sięgnąć danych i kto nimi rozporządza. Dane mogą leżeć w UE, a mimo to podlegać żądaniom organów USA, jeśli operatorem jest podmiot podlegający prawu USA.
Czy CLOUD Act obejmuje dane w europejskich regionach AWS, Azure i Google?
Potencjalnie tak. CLOUD Act pozwala zobowiązać dostawcę podlegającego jurysdykcji USA do wydania danych niezależnie od ich fizycznej lokalizacji. Region w UE ogranicza inne ryzyka, ale nie usuwa faktu, że spółka matka podlega prawu amerykańskiemu.
Czy korzystanie z amerykańskiej chmury łamie RODO?
Nie, jeśli odbywa się w oparciu o ważny mechanizm transferu – obecnie EU-US Data Privacy Framework lub standardowe klauzule umowne z oceną ryzyka. DPF jest jednak kwestionowany prawnie, więc model oparty wyłącznie na nim niesie ryzyko regulacyjne w dłuższym horyzoncie.
Czym jest FISA 702 i dlaczego dotyczy polskich firm?
To przepis pozwalający wywiadowi USA pozyskiwać dane osób spoza USA od dostawców podlegających jurysdykcji USA. Dotyczy więc dokładnie europejskich firm korzystających z amerykańskiej chmury. Był kluczowym powodem unieważnienia Privacy Shield w wyroku Schrems II.
Czy polska chmura jest lepsza od hyperscalera?
Nie w kategoriach absolutnych. Hyperscaler wygrywa skalą globalną i katalogiem usług zarządzanych. Polska chmura wygrywa jurysdykcją (poza zasięgiem Cloud Act), przewidywalnością kosztów (brak egress) i wsparciem. Wybór zależy od profilu danych i wymogów regulacyjnych.
Ile kosztuje transfer danych (egress) u hyperscalera?
Typowo rzędu 0,05-0,09 USD za GB wyjścia, zależnie od dostawcy i kierunku. Przy dużym ruchu to istotna i trudna do prognozy pozycja rachunku. W modelu Engave egress nie jest dodatkowo płatny.
Czy muszę przenosić wszystkie dane do polskiej chmury?
Nie. Rekomendujemy klasyfikację: dane wrażliwe, regulowane i kosztowo zmienne do polskiej chmury, globalne usługi zarządzane i dane jawne mogą zostać u hyperscalera. Najczęściej optymalny jest model hybrydowy.
Jak DORA i NIS2 wpływają na wybór dostawcy chmury?
Oba reżimy wymagają zarządzania ryzykiem dostawców ICT, a DORA dodatkowo udokumentowanej strategii wyjścia. Dostawca w polskiej jurysdykcji upraszcza audyt, prawo właściwe umowy i kwestię transferu danych. Interpretację wymogów warto potwierdzić z prawnikiem lub IOD.
Skonsultuj architekturę swoich danych
Nie wiedzą Państwo, które dane powinny zostać w Polsce, a które mogą pozostać u hyperscalera? Umówmy konsultację architektury. Przejdziemy przez Państwa obciążenia według checklisty klasyfikacji z tego artykułu, wskażemy, gdzie leży realne ryzyko jurysdykcyjne i kosztowe, i zaproponujemy kolejność ewentualnej migracji. Bez presji przenoszenia wszystkiego naraz.