Suwerenna chmura w Europie: rezydencja danych to nie to samo co jurysdykcja.

Ta strona przedstawia perspektywę inżynierską. Jeśli Twój DPO, audytor lub dział zakupów pyta, co „suwerenność” faktycznie oznacza w 2026 roku, to jest wersja, która wytrzyma dokładną kontrolę.

Rezydencja a suwerenność: rozróżnienie, które decyduje o wszystkim

Branża cloud computingu przez piętnaście lat uczyła kupujących zadawania niewłaściwego pytania. „Gdzie hostowane są dane?” to pytanie o rezydencję. Odpowiedź może być technicznie poprawna i jednocześnie prawnie bez znaczenia, ponieważ suwerenność nie dotyczy geografii. Dotyczy tego, które sądy mogą zmusić dostawcę do działania.

Region EU u amerykańskiego hyperscalera, taki jak AWS Frankfurt, Azure West Europe czy GCP Belgium, sprawia, że dane fizycznie pozostają w UE. Nie wyłącza to jednak spółki-matki spod jurysdykcji USA. Na mocy US CLOUD Act (2018) dostawca z siedzibą w USA może zostać zobowiązany do ujawnienia danych klientów przechowywanych gdziekolwiek na świecie, w tym w regionach EU. FISA 702 nakłada analogiczne ryzyko po stronie nadzoru wywiadowczego. Europejska Rada Ochrony Danych wprost wskazała to jako problem w kontekście Schrems II.

„Suwerenny” oznacza więc trzy konkretne rzeczy jednocześnie:

1. Podmiot prawny przechowujący Twoje dane nie ma spółki macierzystej w kraju trzecim posiadającym eksterytorialne przepisy dotyczące ujawniania danych.
2. Żaden subprocesor w ścieżce danych nie znajduje się również w takim kraju.
3. To Ty, a nie dostawca, kontrolujesz klucze szyfrowania, lub klucze znajdują się u depozytariusza poza krajem trzecim.

Spełnij wszystkie trzy warunki, a masz suwerenność. Nie spełnij choćby jednego, a masz jedynie rezydencję danych. Terminologia w Twojej umowie DPA, polityce prywatności i na stronach klienckich powinna odzwierciedlać to, z czym faktycznie masz do czynienia.

Dlaczego "spółka zależna w UE" nie jest odpowiedzią

Powszechnym obejściem promowanym przez amerykańskich hyperscalerów jest struktura europejskiej spółki zależnej. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. Argument jest taki, że to europejski podmiot jest stroną umowy na gruncie prawa UE.

To nie rozwiązuje problemu jurysdykcyjnego. Zgodnie z CLOUD Act, kryterium nie jest to, która spółka zależna podpisała umowę. Liczy się to, czy spółka macierzysta ma „posiadanie, powiernictwo lub kontrolę” nad danymi. Spółka zależna w pełni należąca do UE jest z definicji kontrolowana przez spółkę macierzystą. Analiza CJEU i EDPB w sprawie Schrems II traktuje narażenie spółki macierzystej jako czynnik decydujący.

Gdy więc dostawca oferuje „europejski” plan obsługiwany przez unijną spółkę zależną amerykańskiej grupy, właściwym pytaniem jest: „Czy Twoja amerykańska spółka macierzysta może zostać zobowiązana do polecenia Wam ujawnienia danych bez naszej zgody lub wiedzy?”. Uczciwa odpowiedź brzmi: tak.

Pseudosuwerenna warstwa pośrednia

Lata 2024-2026 przyniosły falę ogłoszonych „suwerennych” partnerstw, zazwyczaj z europejskim integratorem systemów licencjonującym stos technologiczny amerykańskiego hyperscalera i obsługującym go pod europejskim zarządem. Przykłady dostępne dziś na rynku:

• Licencjonowane suwerenne oferty, zbudowane na technologii amerykańskiego hyperscalera, obsługiwane przez europejską spółkę zależną Telekomu.
• Bleu, francuska suwerenna chmura zbudowana na technologii Microsoft Azure, obsługiwana przez Capgemini i Orange.
• S3NS, joint venture Thales i Google we Francji.

Takie oferty mogą być przydatne w przypadku konkretnych reżimów zgodności, ale nie powinny być przez zespół inżynieryjny nazywane suwerennymi bez zastrzeżeń. Stos technologiczny, aktualizacje platformy, poprawki bezpieczeństwa, a co kluczowe - operacyjne know-how, pochodzą od amerykańskiego partnera. W najgorszym scenariuszu zagrożenia, gdy strona amerykańska wycofa współpracę lub zostanie do tego zmuszona, europejski operator dziedziczy stos, którego nie jest w stanie samodzielnie utrzymać.

Dla większości kupujących czystszą architektonicznie odpowiedzią jest budowanie na infrastrukturze, w której w łańcuchu dostaw nie ma żadnej zależności od USA. To właśnie mamy na myśli, mówiąc o suwerennym stosie w Binadit.

Jak faktycznie wygląda suwerenny stos UE

Poniżej konkretna architektura referencyjna dla obciążenia SaaS klasy mid-market lub regulowanego, działającego całkowicie pod jurysdykcją UE. Żadne z tych rozwiązań nie jest egzotyczne; wszystkie są klasy produkcyjnej.

• Compute i storage: zarządzany compute Binadit oraz dedykowany sprzęt, na infrastrukturze UE pod jurysdykcją UE.
• Object storage: Ceph lub MinIO, kompatybilne z S3, obsługiwane przez nas na tej samej infrastrukturze.
• CDN: Bunny.net (SI), KeyCDN (CH) lub samodzielnie zarządzana warstwa brzegowa dla pełnej kontroli.
• DNS: PowerDNS lub Knot, autorytatywne i podpisane DNSSEC, lub Bunny DNS, gdy chcesz mieć to zintegrowane z CDN.
• Dostarczanie e-maili: Mailgun EU (z zachowaniem ostrożności, ze względu na amerykańską spółkę-matkę), lub w pełni europejskie opcje jak Postmark EU, Mailpace, Tuta business, lub self-hosted Postfix na tej samej infrastrukturze.
• Śledzenie błędów: self-hosted GlitchTip lub Sentry, lub wdrożenie Sentry w regionie UE z udokumentowanymi kompromisami.
• Analityka: Plausible (hostowane w UE), Matomo (self-hosted lub chmura UE), Pirsch.
• Observability: Self-hosted Prometheus + Grafana + Loki, lub zarządzane w UE odpowiedniki (Grafana Cloud EU, Last9 z regionem EU).
• Zarządzanie kluczami: Hashicorp Vault na infrastrukturze UE, lub zarządzani przez UE dostawcy KMS; w scenariuszach wymagających wysokiego zaufania, lokalny HSM z BYOK po stronie chmury.
• CI/CD: GitLab self-hosted, Forgejo, Gitea lub instancja GitLab.com EU. Nigdy domyślny github.com dla kodu dotyczącego danych osobowych bez dodatkowych zabezpieczeń.

Chodzi nie o to, że którekolwiek z tych rozwiązań jest „tą jedyną słuszną” odpowiedzią. Chodzi o to, że cały stos technologiczny można zbudować z dostawców z siedzibą w UE, a partner zarządzający infrastrukturą może go dla Ciebie prowadzić tak samo, jak partner natywny dla AWS prowadziłby AWS.

Test czterech pytań, szczegółowo

1. Rezydencja: gdzie dokładnie

Nie "w UE", ale które centrum danych, w którym kraju, pod jaką jurysdykcją. UE nie jest jednolitym systemem prawnym; RODO jest zharmonizowane, ale organ nadzorczy jest lokalny, podobnie jak środki ochrony prawnej w przypadku awarii dostawcy. Udokumentuj kod kraju dla lokalizacji podstawowej, wtórnej i zapasowej w swojej umowie DPA.

2. Subprocesorzy: każdy z nich

W naszych audytach środowisk klasy mid-market niezmapowany łańcuch subprocesorów jest najczęstszym znaleziskiem. Aplikacja działa na infrastrukturze UE, co jest dobre. Ale API do optymalizacji obrazów, które wywołuje, jest hostowane w USA. Poczta transakcyjna wysyłana jest przez amerykańskiego ESP. Tracker błędów to domyślny amerykański. Widget wsparcia klienta wczytuje JavaScript z amerykańskiego CDN. Każdy z nich to odrębny przepływ danych. Każdy wymaga podstawy prawnej, jeśli dane przekazywane są do państwa trzeciego.

Suwerenny stack wymaga pełnej listy subprocesorów, obejmującej również zewnętrzne API wykorzystywane przez Twoją aplikację, a nie tylko dostawców infrastruktury. Nasza jest w pełni wskazana w umowie powierzenia przetwarzania danych i prześlemy ją, zanim cokolwiek podpiszesz.

3. Jurysdykcja: kto może wymusić ujawnienie danych

Kwestia procesu prawnego. Dla każdego podmiotu w Twojej ścieżce przetwarzania danych zidentyfikuj siedzibę spółki macierzystej. Jeśli którakolwiek spółka macierzysta znajduje się w USA, Chinach, Rosji lub innym kraju z eksterytorialnymi przepisami o dostępie do danych, ten podmiot jest narażony. Status unijnej spółki zależnej amerykańskiej spółki macierzystej tego nie rozwiązuje.

To właśnie w tym miejscu diagram architektury staje się dokumentem prawnym. Narysuj go raz, przeglądaj co kwartał.

4. Zarządzanie kluczami: kto technicznie może odczytać dane

Szyfrowanie w spoczynku jest konieczne, ale niewystarczające. Pytanie brzmi, kto posiada klucze. Klucze zarządzane przez dostawcę nie chronią przed sytuacją, w której dostawca zostaje zobowiązany do odszyfrowania danych. BYOK (Bring Your Own Key) pomaga w narracji zgodności; dostawca nadal posiada kopię roboczą klucza. HYOK (Hold Your Own Key) to jedyny model, w którym dostawca chmury fizycznie nie jest w stanie odczytać danych bez aktywnego zapytania do Twojego opiekuna kluczy. Wybierz model, jakiego wymaga model zagrożeń.

Ścieżka migracji: od AWS Frankfurt do suwerennego stosu technologicznego

Obawa przed odejściem od hyperscalera jest zwykle większa niż sam projekt. Typowa migracja w segmencie mid-market przebiega w trzech fazach:

1. Inwentaryzacja i audyt (1-2 tygodnie). Zmapuj każdy przepływ danych, zidentyfikuj każdego subprocesora, sklasyfikuj według ekspozycji na USA. Rezultat: lista działań naprawczych uszeregowana według ryzyka i złożoności migracji.
2. Szybkie usunięcia (2-4 tygodnie). Zastąp najpierw miękkie zależności: error tracking, analytics, CDN, DNS, email. Można je zmienić przy niewielkiej lub żadnej ingerencji w aplikację.
3. Migracja kluczowych zasobów (4-8 tygodni). Compute, storage, baza danych. Użyj replikacji strumieniowej dla migracji bazy danych bez przestojów; użyj wzorców blue-green lub DNS-failover na warstwie aplikacji. Najtrudniejsza rzadko jest sama technologia. To choreografia stanowi wyzwanie.

Całkowity czas potrzebny zespołowi inżynierskiemu liczącemu 6-8 osób, wykonującemu tę pracę obok swoich codziennych obowiązków: dziesięć do szesnastu tygodni. Z partnerem zarządzającym infrastrukturą prowadzącym migrację: cztery do dwunastu. Różnica kosztów między utrzymywaniem suwerennego stosu a hyperscalerem jest, w naszym doświadczeniu, neutralna do ujemnej dla przewidywalnych obciążeń, umiarkowanie wyższa dla obciążeń zmiennych, i znacząco niższa, gdy uwzględni się egress i przepustowość.

Czy suwerenna chmura jest droższa? Uczciwa odpowiedź

W przypadku 80% obciążeń klasy mid-market suwerenny stos jest tańszy w perspektywie pięciu lat, głównie dlatego, że dostawcy z UE nie naliczają karnych opłat za egress, a ceny rozwiązań dedykowanych i bare-metal są znacząco lepsze niż odpowiadające im typy instancji u hyperscalerów. Przypadki, w których suwerenny stos jest droższy, to: wysoce zmienne obciążenia korzystające z autoskalowania w czasie poniżej jednej sekundy, obciążenia oparte na konkretnej usłudze zarządzanej (DynamoDB, BigQuery, Lambda) bez czystego odpowiednika, oraz obciążenia treningowe ML wymagające konkretnej generacji akceleratora.

Kompetentny przegląd inżynierski powie Ci w tydzień, do której kategorii należysz. Jeśli chcesz go przeprowadzić, to właśnie tym się zajmujemy.

Wiatr regulacyjny w plecy: NIS2, DORA, EHDS i AI Act

Kierunek zmian regulacyjnych w latach 2025-2027 zmierza w stronę ściślejszej odpowiedzialności w łańcuchu dostaw:

• NIS2 (Artykuł 21): podmioty kluczowe i ważne muszą przeprowadzać oceny ryzyka łańcucha dostaw i umownie przenosić obowiązki bezpieczeństwa na subprocesorów. Subprocesor podlegający jurysdykcji USA jest trudny do obrony w takiej ocenie bez dodatkowych zabezpieczeń.
• DORA (obowiązuje od stycznia 2025): podmioty finansowe muszą prowadzić rejestr dostawców ICT będących stronami trzecimi oraz strategię wyjścia dla dostawców krytycznych. Zapisy dotyczące ryzyka koncentracji wprost odnoszą się do zależności od dominujących dostawców spoza UE.
• European Health Data Space (EHDS): wtórne wykorzystanie danych zdrowotnych jest ograniczone do środowisk przetwarzania podlegających jurysdykcji UE.
• EU AI Act: systemy AI wysokiego ryzyka wymagają możliwej do prześledzenia proweniencji danych treningowych, co w praktyce jest bardzo trudne przy korzystaniu z amerykańskiego API modelu podstawowego.

Żadne z tych regulacji nie zakazuje dostawców z USA. Sprawiają jednak, że obciążenie dokumentacją i środkami uzupełniającymi jest na tyle wysokie, że w większości przypadków suwerenny stos jest opcją niższego tarcia.

Czego nie twierdzimy

Dla uczciwości: istnieją obciążenia, w których suwerenny stos UE jest trudniejszy do zrealizowania niż u hyperscalera. Multi-region active-active z globalnym opóźnieniem poniżej 50ms. Konkretne zarządzane hurtownie analityczne. Wnioskowanie ML na skalę hyperscale na najnowszych akceleratorach. Powiemy Ci, gdy Twoje obciążenie znajdzie się w tej kategorii. W przypadku 90% SaaS, e-commerce, platform B2B i regulowanych obciążeń, które obserwujemy, suwerenny stos nie jest tylko zgodny z przepisami. Jest też szybszy, tańszy i łatwiejszy do analizy.

Gdzie wpasowuje się Binadit

Jesteśmy podmiotem przetwarzającym dane zgodnie z Artykułem 28, z siedzibą w Rotterdamie, w Holandii. Nasza infrastruktura znajduje się w 100% u dostawców z siedzibą w UE. Nasza lista podprocesorów jest w pełni wymieniona w umowie powierzenia przetwarzania danych i dostępna na żądanie. Nie podejmujemy się projektów, które wymagałyby podprocesora podlegającego jurysdykcji USA w domyślnej ścieżce danych. Jeśli dane obciążenie faktycznie tego wymaga (np. usługa SaaS strony trzeciej, przy której klient obstaje), dokumentujemy to pisemnie, uwzględniamy środki uzupełniające i przedstawiamy pozostałe ryzyko IOD przed podpisaniem umowy.

Jeśli to brzmi jak partner, którego szukałeś, następnym krokiem jest 30-minutowa rozmowa wstępna.