Rezydencja danych w UE dla LLM: gdzie przetwarzane są Twoje dane

Rezydencja danych w UE dla LLM oznacza, że prompty, odpowiedzi modelu, embeddingi i logi są przechowywane i przetwarzane wyłącznie w regionie UE. Ma to znaczenie z punktu widzenia ochrony danych, ponieważ każde przetwarzanie poza EOG jest przekazaniem danych do państwa trzeciego w rozumieniu rozdziału V RODO i wymaga podstawy transferu, takiej jak decyzja o adekwatności lub standardowe klauzule umowne.

• Rezydencja danych = miejsce przetwarzania. Jeśli przepływ danych opuszcza EOG, zastosowanie ma rozdział V RODO: potrzebna jest decyzja o adekwatności albo instrument transferu z art. 46, np. standardowe klauzule umowne (SKU), a w tym drugim przypadku dodatkowo ocena skutków transferu (TIA).
• Hosting w UE jest możliwy u większości dużych dostawców, ale warunkowo i czasem tylko okrężną drogą. Azure OpenAI przez EU Data Boundary, Claude tylko przez AWS Bedrock EU lub Vertex EU, Vertex przez regionalne endpointy UE, Mistral jako dostawca z UE.
• Sam region UE nie rozwiązuje problemu. Dostawcy z USA mimo regionu w UE nadal podlegają amerykańskiemu CLOUD Act; suwerenni dostawcy z regionu DACH (Niemcy, Austria, Szwajcaria) całkowicie omijają kwestię państw trzecich.

Czym jest rezydencja danych i dlaczego ma znaczenie dla RODO

Rezydencja danych określa miejsce geograficzne, w którym dane osobowe są przechowywane i przetwarzane. W systemie opartym na LLM miejsce to nie ogranicza się do inferencji. Zgodnie z art. 4 pkt 1 i 2 RODO każda operacja na danych osobowych jest przetwarzaniem. W stacku agentowym obejmuje to co najmniej:

• Dane wejściowe inferencji: prompty, prompty systemowe, załączone pliki, próbki głosu.
• Dane wyjściowe inferencji: teksty i podsumowania, które wymieniają lub opisują osoby (także zhalucynowane dane osobowe).
• Pamięć agenta: okno kontekstowe, pamięć epizodyczna i semantyczna, trwałe bazy wektorowe.
• Embeddingi i bazy wektorowe: zarówno zindeksowany tekst, jak i same wektory uznaje się za dane osobowe spseudonimizowane, ponieważ ataki inwersyjne i ataki typu membership inference umożliwiają ponowną identyfikację.
• Logi i ślady wykonania: logi promptów, logi odpowiedzi modelu, spany z narzędzi observability.

Kluczowa kwestia: każdy z tych elementów może znajdować się w innym miejscu. Inferencja z rezydencją w UE niewiele daje, jeśli baza wektorowa, backend observability albo kolejny serwer MCP w łańcuchu przesyła dane do państwa trzeciego.

Przekazanie danych do państwa trzeciego jako czynnik wyzwalający

Gdy tylko dane osobowe opuszczają EOG, mamy do czynienia z przekazaniem danych do państwa trzeciego w rozumieniu rozdziału V RODO. Kluczowy jest tu wyrok TSUE Schrems II (C-311/18, 16 lipca 2020 r.): unieważnił on Tarczę Prywatności (Privacy Shield) i wyjaśnił, że standardowe klauzule umowne (SKU) pozostają ważne tylko w połączeniu z oceną skutków transferu przeprowadzoną dla konkretnego przypadku, w razie potrzeby wraz ze środkami uzupełniającymi. Komisja przełożyła to na praktykę w SKU 2021/914 (4 czerwca 2021 r.), podzielonych na cztery moduły.

Dlatego rezydencja danych w UE to najskuteczniejszy sposób, by problem z transferem w ogóle nie powstał: jeśli wszystkie warstwy przetwarzania pozostają w EOG, przekazanie do państwa trzeciego przestaje być punktem kontroli.

Status EU-US Data Privacy Framework (stan na 2026, z zastrzeżeniem zmian)

Gdy transferu do USA nie da się uniknąć, kluczowym instrumentem jest EU-US Data Privacy Framework (DPF). Komisja przyjęła decyzję o adekwatności 10 lipca 2023 r. (DPF zastąpił Tarczę Prywatności). 3 września 2025 r. Sąd Unii Europejskiej oddalił w sprawie Latombe v Commission (T-553/23) pierwszą skargę i potwierdził ważność DPF w chwili jego przyjęcia.

Kwestie otwarte (stan na październik 2026, z zastrzeżeniem zmian):

• 31 października 2025 r. Latombe wniósł odwołanie do TSUE; postępowanie jest w toku.
• NOYB/Max Schrems zapowiedział własną, szerszą skargę. Powodem jest wyrok Sądu Najwyższego USA w sprawie Trump v. Slaughter: zgodnie z nim prezydent USA może odwoływać członków FTC bez podania przyczyny (beck-aktuell). FTC jest jednym z organów nadzorczych, na których opiera się DPF. Dlatego pod koniec czerwca 2026 r. NOYB wezwał Komisję do uporządkowanego wycofania decyzji o adekwatności. Już wcześniej NOYB kwestionował niezależność Privacy and Civil Liberties Oversight Board (PCLOB) z powodu amerykańskich rozporządzeń wykonawczych (executive orders). Scenariusz „Schrems III” pozostaje więc realny.
• Sąd UE wyraźnie stwierdził, że Komisja musi stale monitorować ramy prawne i może zawiesić, zmienić lub uchylić decyzję, jeśli warunki się zmienią.

Konsekwencja operacyjna: certyfikacja DPF jest obecnie ważną podstawą transferu. Transfer na podstawie decyzji o adekwatności nie wymaga szczególnego zezwolenia (art. 45 ust. 1 RODO) ani dodatkowych zabezpieczeń (art. 46 ust. 1 RODO). Mimo to firmy powinny utrzymywać SKU jako rozwiązanie awaryjne. TIA nie jest wymagana w przypadku odbiorców z certyfikacją DPF, ale warto ją przygotować na wypadek, gdyby DPF upadł i transfer trzeba było przestawić na SKU. Dla Szwajcarii obowiązuje Swiss-US DPF (w mocy od 15 września 2024 r.). Sama Szwajcaria jest uznawana za kraj zapewniający odpowiedni stopień ochrony od 2000 r. (decyzja Komisji 2000/518/WE); Komisja potwierdziła to 15 stycznia 2024 r. w przeglądzie jedenastu starszych decyzji o adekwatności.

Dlaczego region UE nie eliminuje ryzyka związanego z CLOUD Act

Region UE rozwiązuje kwestię miejsca przechowywania, a nie jurysdykcji, której podlega dostawca. Dlatego w TIA dla dostawców AI pozostają następujące ryzyka:

• Amerykański CLOUD Act: ryzyko dostępu w przypadku dostawców z USA i ich spółek zależnych w EOG, niezależnie od tego, gdzie fizycznie znajdują się dane.
• FISA 702 / EO 12333: ekspozycja dostawców usług łączności elektronicznej (np. Microsoft, Google, AWS).
• Środki zaradcze: szyfrowanie danych w spoczynku i w tranzycie jako minimalny standard; coraz częściej szyfrowanie w użyciu (confidential computing, TEE); BYOK/HYOK, tak aby dostawca nie mógł odszyfrować danych bez udziału administratora.

Właśnie tu leży przewaga suwerennych dostawców z regionu DACH: nie podlegają jurysdykcji USA i przetwarzają dane wyłącznie w Niemczech/UE lub w Szwajcarii.

Opcje hostingu w UE u dużych dostawców

Poniższe zestawienie podsumowuje opcje rezydencji danych. To podsumowanie researchu, a nie porada prawna; warunki dostawców często się zmieniają i trzeba je ponownie sprawdzić przy zawieraniu umowy.

Jak czytać tabelę

Wyraźnie widać trzy prawidłowości. Po pierwsze: hiperskalerzy oferują regiony UE, ale uzależniają je od konfiguracji (region pinning), a czasem od dopłat, np. za endpointy regionalne w Vertex. Po drugie: Anthropic Claude może mieć rezydencję w UE tylko pośrednio, czyli przez AWS Bedrock EU lub Vertex EU, a nie przez bezpośrednie API. Według dokumentacji Anthropic (stan na październik 2026) bezpośrednie API zna tylko regiony inferencji „us” i „global”. Po trzecie: suwerenni dostawcy z regionu DACH (IONOS, STACKIT, Open Telekom Cloud, Aleph Alpha, Swisscom) oferują jedyną opcję z przetwarzaniem wyłącznie w Niemczech/UE lub w Szwajcarii i bez ryzyka jurysdykcji USA.

Przykład liczbowy: rezydencja danych w stacku podmiotów podprzetwarzających

Typowy stack wdrożeniowy oparty na agentach obejmuje od pięciu do ośmiu warstw podmiotów podprzetwarzających: dostawcę modelu bazowego, hosting/chmurę, orkiestrację, bazę wektorową, dostawcę pamięci, serwer MCP, observability i ewaluację.

Weźmy konkretną konfigurację: austriacka firma prowadzi agenta obsługi klienta na Claude przez AWS Bedrock w regionie UE (warstwy 1 + 2, rezydencja w UE). Baza wektorowa znajduje się w UE (warstwa 4, rezydencja w UE). Ale narzędzie observability (warstwa 7) wysyła ślady promptów do backendu w USA, a podłączony serwer MCP (warstwa 6) amerykańskiego dostawcy przetwarza payloady wywołań narzędzi globalnie.

Rachunek: z 8 warstw 6 ma rezydencję w UE, a 2 kierują dane do państwa trzeciego. To nie wystarcza do rezydencji danych w UE. Już jedna warstwa w państwie trzecim sprawia, że cały przepływ danych staje się transferem podlegającym rozdziałowi V, z podstawą transferu (DPF lub SKU wraz z TIA) i ryzykiem rezydualnym wynikającym z CLOUD Act. Najczęstsze ustalenia audytowe dotyczą właśnie tych niewidocznych warstw: nieujawnionych przepływów do serwerów MCP i dostawców observability bez umowy powierzenia.

Konkretna skala kar dla porównania: Clearview AI została ukarana za niezgodne z prawem przetwarzanie danych we Włoszech kwotą 20 mln euro (10 lutego 2022 r.) i we Francji kwotą 20 mln euro (17 października 2022 r.); włoski Garante nałożył na OpenAI karę 15 mln euro (decyzja z 2 listopada 2024 r.). Dyscyplina w przepływach danych nie jest więc ćwiczeniem teoretycznym.

Praktyczne konsekwencje dla wyboru dostawcy

• Zapisz region pinning w umowie. Domyślny globalny routing i failover dostawcy do regionów spoza UE to częste ustalenia audytowe. Rezydencja musi być określona w umowie powierzenia, a nie tylko dawać się skonfigurować.
• Sprawdź wszystkie warstwy, nie tylko inferencję. Bazę wektorową, pamięć, serwery MCP i observability sprawdź osobno pod kątem rezydencji i umowy powierzenia; zapewnij nieprzerwany łańcuch zgodny z art. 28 ust. 4.
• Przy dostawcach z USA zabezpiecz się podwójnie. Zweryfikuj certyfikację DPF, utrzymuj SKU jako rozwiązanie awaryjne, udokumentuj TIA.
• W sektorach wrażliwych rozważ opcje suwerenne. W silnie regulowanych obszarach (np. usługi finansowe objęte tajemnicą bankową na podstawie art. 47 BankG w Szwajcarii) suwerenne rozwiązania chmurowe i on-premise w praktyce wysuwają się na pierwszy plan.

Dla agencji i decydentów B2B

Rezydencja danych to nie tylko szczegół IT, ale kwestia umowna i architektoniczna, która powinna pojawić się wcześnie w procesie wyboru dostawcy. Dla agencji budujących agentów AI dla klientów w Europie architektura zgodna z wymogami rezydencji jest cechą jakości, którą da się sprzedać: udokumentowany przepływ danych w UE przez wszystkie warstwy podmiotów podprzetwarzających wymiernie zmniejsza ryzyko związane z państwami trzecimi u Twoich klientów. Dla decydentów B2B zasada jest taka: zanim przejdziesz na produkcję, zażądaj od dostawcy pełnej mapy podmiotów podprzetwarzających z lokalizacją i funkcją każdej warstwy. Blck Alpaca wspiera ocenę opcji rezydencji w UE, dokumentację TIA i budowę stacków agentowych zgodnych z wymogami rezydencji.

Uwaga: ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. Aby uzyskać wiążącą ocenę Twojego konkretnego przypadku, skonsultuj się z prawniczką lub prawnikiem albo z Twoim inspektorem ochrony danych.