Azure OpenAI i Amazon Bedrock a RODO: jak trzymać zapytania do modeli w UE

Które typy wdrożeń Azure OpenAI utrzymują przetwarzanie w UE

Tylko dwa rodzaje wdrożeń w Azure utrzymują inferencję w UE: wdrożenia Data Zone utworzone w zasobie w regionie UE oraz wdrożenia Standard lub Regional Provisioned w geografii UE. Każdy typ Global może przetwarzać prompty poza UE, nawet jeśli sam zasób znajduje się w regionie UE.

Strona Microsoftu o typach wdrożeń, zaktualizowana 12 sierpnia 2026, rozdziela dwie rzeczy, które często się myli. Dane w spoczynku (at rest), na przykład przesłane pliki, zostają w geografii Azure, w której jest zasób, niezależnie od typu wdrożenia. Przetwarzanie, czyli inferencja, która czyta twój prompt i generuje odpowiedź, zależy od typu wdrożenia. Zasób w regionie UE z wdrożeniem Global Standard przechowuje więc dane w UE, ale może je przetwarzać wszędzie. To właśnie ta kombinacja stoi za większością pytań w stylu „wybraliśmy region w UE, więc dlaczego dane mogą go opuścić?”.

Dwa szczegóły powinny trafić do twojej dokumentacji. Strona Microsoftu o prywatności danych mówi, że wdrożenie w strefie danych UE może przetwarzać prompty w dowolnym państwie członkowskim UE. Strona o typach wdrożeń dodaje, że strefa danych UE pokrywa się z EU Data Boundary, która może obejmować państwa EFTA, takie jak Norwegia i Szwajcaria, oraz że Microsoft może dodawać regiony do strefy danych bez uprzedzenia. Jeśli twój wymóg dotyczy jednego kraju, a nie całej UE, najbliżej jest tylko wdrożenie Standard w geografii tego kraju, a i ono może przenosić obciążenie między regionami w tej geografii.

Nie każdy model jest dostępny w każdym typie wdrożenia i regionie. Zanim zdecydujesz się na model, sprawdź aktualną dostępność w Microsofcie dla Data Zone Standard i Standard w twoim regionie. Model oferowany tylko jako Global Standard odpada przy wymogu tylko UE, niezależnie od tego, jak jest dobry.

Kto widzi twoje prompty w Azure

W przypadku modeli, które Microsoft sprzedaje w Foundry, w tym modeli Azure OpenAI, OpenAI nie dostaje twoich promptów i nie są one używane do trenowania. Z Claude w Foundry jest inaczej, a w abuse monitoring mogą uczestniczyć pracownicy Microsoftu. Strona Microsoftu o prywatności danych, zaktualizowana 5 czerwca 2026, mówi, że prompty i odpowiedzi nie są dostępne dla OpenAI ani innych dostawców modeli sprzedawanych przez Azure, nie są przez nich używane do ulepszania modeli i nie służą do trenowania generatywnych modeli bazowych bez twojej zgody lub polecenia. Dodaje też, że modele są bezstanowe i nie komunikują się z usługami prowadzonymi przez OpenAI, takimi jak ChatGPT czy OpenAI API.

Modele Claude w Foundry to osobny przypadek. Porównanie hostingu od Microsoftu, zaktualizowane 22 września 2026, mówi, że Anthropic sprzedaje i obsługuje Claude w Foundry i działa jako niezależny podmiot przetwarzający prompty i odpowiedzi, na podstawie data processing addendum i warunków handlowych Anthropic. Claude hostowany w Azure jest dostępny jako Global Standard i Data Zone Standard (US). Claude hostowany przez Anthropic jest dostępny tylko jako Global Standard, a dane mogą być przetwarzane poza Azure. Na 7 listopada 2026 nie ma dla Claude w Foundry opcji strefy danych UE, więc przy wymogu tylko UE odpada.

Abuse monitoring i kto może go wyłączyć

Abuse monitoring jest domyślnie częścią usługi. Automatyczne klasyfikatory sprawdzają prompty i odpowiedzi, a według Microsoftu treści, które przechodzą tylko automatyczną kontrolę, nie są zapisywane. Treści oznaczone przez system mogą być przechowywane do ręcznej weryfikacji w magazynie danych w geografii twojego zasobu, także przy wdrożeniach Global i Data Zone. Dostęp mają tylko upoważnieni pracownicy Microsoftu, przez zabezpieczone stacje robocze z zatwierdzeniem just-in-time, a dla modeli wdrożonych w Europejskim Obszarze Gospodarczym ci weryfikatorzy znajdują się w EOG.

Sam go nie wyłączysz. Strona Microsoftu o ograniczonym dostępie mówi, że modified abuse monitoring jest dostępny tylko dla klientów i partnerów obsługiwanych przez zespół opiekunów Microsoftu lub objętych odpowiednim programem, na wniosek, a dla niektórych zaawansowanych modeli obowiązują ostrzejsze kryteria. Po zatwierdzeniu zapisywanie i ręczna weryfikacja nie są wykonywane, ale automatyczna kontrola może nadal działać. Aktualne strony Microsoftu, które sprawdziliśmy 7 listopada 2026, nie podają okresu przechowywania dla magazynu abuse monitoring. Na forach krążą liczby w rodzaju 30 dni. Zamiast na nich polegać, poproś Microsoft o pisemne potwierdzenie obecnego okresu.

Niektóre funkcje z założenia przechowują treści. Responses API, wątki w Assistants API i stored completions tworzą magazyn na historię wiadomości, a pliki przesłane do fine-tuningu, zadań wsadowych lub vector store są przechowywane w zasobie w jego geografii. Global Batch trzyma oczekujące dane w spoczynku w twojej geografii, ale może je przetwarzać wszędzie, gdzie model jest wdrożony.

Jak trzymać wywołania Amazon Bedrock w UE i co przechowuje AWS

W Bedrock przetwarzanie w UE zależy od identyfikatora modelu, który wywołujesz: model w regionie UE albo geograficzny profil inferencji dla UE utrzymuje zapytania w UE, a profil globalny nie.

Artykuł w AWS re:Post Knowledge Center o wykorzystaniu danych mówi, że Bedrock nie przechowuje danych wejściowych i wyjściowych klientów, nie udostępnia ich zewnętrznym dostawcom modeli i nie używa ich do trenowania modeli. Przewodnik użytkownika Bedrock dodaje, że model każdego dostawcy działa na koncie model deployment account, którego właścicielem i operatorem jest zespół Bedrock i do którego dostawca nie ma dostępu, więc dostawcy nie widzą twoich promptów, odpowiedzi ani logów Bedrock.

To ogólne stwierdzenie ma wyjątki dla wykrywania nadużyć, zależne od modelu. Na 7 listopada 2026 strona Bedrock o abuse detection podaje, że ruch oznaczony przez klasyfikator dla niektórych modeli OpenAI oraz cały ruch dla Claude Fable 5 i Claude Fable 5.1 jest przechowywany do 30 dni, przy czym oznaczony ruch tych modeli Claude może ręcznie sprawdzić AWS. Przechowywane dane zostają w AWS, nie trafiają do dostawcy modelu, a przy inferencji międzyregionalnej są zapisywane w regionie docelowym, w którym zapytanie zostało wykonane. Strona o przechowywaniu danych pozwala ustawić tryb przechowywania dla każdego regionu. W trybie none zapytania do modeli, które wymagają przechowywania, są blokowane, a nie zapisywane. Przestarzały tryb provider_data_share, o który pytają ludzie na forach, też niczego nie udostępnia: AWS pisze, że Bedrock obecnie nie przekazuje treści dostawcom modeli.

W kwestii profili geograficznych AWS pisze, że profil powiązany z geografią, taką jak UE, utrzymuje zapytania w tej geografii, a jego lista regionów docelowych nigdy się nie zmienia, podczas gdy profile globalne mogą z czasem zyskiwać regiony. AWS ostrzega też, żeby nie polegać na samym prefiksie w ID profilu. Zanim zatwierdzisz profil, odczytaj jego regiony docelowe z twojego regionu źródłowego:

# 1. Active EU profiles available from Frankfurt
aws bedrock list-inference-profiles \
    --region eu-central-1 \
    --type-equals SYSTEM_DEFINED \
    --query "inferenceProfileSummaries[?status=='ACTIVE' && starts_with(inferenceProfileId, 'eu.')].[inferenceProfileId,inferenceProfileName]" \
    --output table

# 2. Destination Regions of one profile, called from Frankfurt
aws bedrock get-inference-profile \
    --region eu-central-1 \
    --inference-profile-identifier <eu-profile-id> \
    --query 'models[].modelArn'

To, które modele są dostępne we Frankfurcie bezpośrednio lub przez profil UE, często się zmienia, więc sprawdzaj aktualną listę modeli i wynik powyższych poleceń, a nie jakikolwiek artykuł, łącznie z tym. Dokumentacja LiteLLM dla Bedrock zaznacza, że nowsze modele Claude przyjmują wywołania on-demand tylko przez profil inferencji, więc dla nich profil UE jest realną opcją w UE.

Jeśli twoja organizacja blokuje nieużywane regiony politykami SCP, inferencja międzyregionalna nie zadziała, dopóki nie dopuścisz regionów docelowych profilu albo nie dodasz wyjątku z warunkiem bedrock:InferenceProfileArn. AWS opisuje też politykę, która całkowicie blokuje profile globalne. Przypnij ją do każdego konta, które może wywoływać Bedrock:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalCrossRegionInference",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "unspecified" },
        "ArnLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*" }
      }
    }
  ]
}

Czy region w UE chroni przed amerykańskim CLOUD Act

Sam w sobie nie. Region w UE decyduje o tym, gdzie dane są przetwarzane i przechowywane. CLOUD Act dotyczy tego, jakiemu prawu musi się podporządkować dostawca. Sekcja 2713 tytułu 18 US Code, dodana przez CLOUD Act w 2018 roku, nakłada na dostawców usług komunikacyjnych i zdalnego przetwarzania obowiązek zabezpieczenia i ujawnienia danych, które posiadają, przechowują lub kontrolują, niezależnie od tego, czy znajdują się w Stanach Zjednoczonych, czy poza nimi. Microsoft i Amazon to firmy amerykańskie, więc wybór Frankfurtu czy strefy danych UE nie wyłącza twoich danych z tego zakresu.

Microsoft sam to przyznał we Francji. Podczas przesłuchania przed komisją śledczą francuskiego Senatu ds. zamówień publicznych 10 czerwca 2025 roku Anton Carniaux z Microsoft France został zapytany, czy może pod przysięgą zagwarantować, że dane obywateli Francji powierzone Microsoftowi przez centralny urząd zakupowy UGAP nigdy nie trafią do władz USA bez wyraźnej zgody Francji. Odpowiedział, że nie może tego zagwarantować, dodał, że jeszcze się to nie zdarzyło, i powiedział, że Microsoft zobowiązuje się umownie kwestionować nieuzasadnione żądania.

Wdrożenie w UE nadal daje sporo. Utrzymuje bieżące przetwarzanie i przechowywane dane w UE, a w Azure weryfikatorzy abuse monitoring dla wdrożeń w EOG pracują w EOG. Naszym zdaniem łatwiej też udokumentować ocenę transferów danych na gruncie RODO. Czy to wystarczy, zależy od danych. Dla większości wewnętrznych asystentów uważamy wdrożenie w UE z kontrolami z następnej sekcji za rozsądny wybór. Jeśli musisz wykluczyć właśnie dostęp obcego rządu, na przykład przy części danych z administracji publicznej, obronności czy ochrony zdrowia, lepiej sprawdzi się dostawca z siedzibą w UE albo własne serwery. Ten przewodnik nie jest poradą prawną. Decyzja należy do twojego inspektora ochrony danych i prawników.

Wymuszanie routingu tylko w UE dla każdego zespołu przez jedną bramę LLM

Najpewniej utrzymasz każdy zespół na endpointach w UE, jeśli brama LLM (LLM gateway) będzie jedyną drogą do modeli i nie będzie znała żadnych innych endpointów poza tymi w UE. Z LiteLLM to sześć kroków:

1. 1

   Wpisz tylko endpointy w UE

   Każdy wpis w model_list wskazuje na wdrożenie Data Zone lub Standard w zasobie Azure w UE, gdzie LiteLLM oczekuje azure/ i nazwy wdrożenia, albo na model Bedrock lub profil eu. z regionem UE w aws_region_name. Umieść region w nazwie wpisu, na przykład z sufiksem -eu, żeby nikt nie musiał zgadywać.

2. 2

   Pomiń wpisy z symbolem wieloznacznym

   Wildcard routing w LiteLLM przekazuje dostawcy każdą nazwę modelu z danym prefiksem, bez wpisywania jej na listę. To wygodne, ale tutaj niweczy cały zamysł, bo klientowi wystarczyłoby wtedy podać nazwę globalnego wdrożenia albo profilu global., żeby do niego dotrzeć.

3. 3

   Wydaj klucze dla zespołów z listą dozwolonych modeli

   Utwórz każdy zespół z listą models i wydawaj mu klucze w ramach tego zespołu. LiteLLM opisuje, że lista models klucza zarówno ukrywa inne modele na liście modeli, jak i blokuje ich wywołania, a zapytanie zespołu o model spoza listy kończy się błędem, który wymienia dozwolone modele.

4. 4

   Trzymaj fallbacki w UE

   Fallbacki prowadzą od jednej model_name do drugiej, cele fallbacku muszą istnieć w routerze, a LiteLLM stosuje do każdego celu fallbacku kontrole dostępu do modeli dla wywołującego klucza i zespołu. Jeśli na liście są tylko wpisy z UE, nawet przy awarii nie ma globalnego wdrożenia, na które dałoby się przełączyć. Zdecyduj, czy awaria regionu ma kończyć zapytanie błędem, czy przenosić je na inne wdrożenie w UE, i zapisz tę decyzję.

5. 5

   Zamknij boczne wejścia

   Trzymaj poświadczenia dostawców wyłącznie w magazynie sekretów bramy, ogranicz, kto może tworzyć wdrożenia w zasobach Azure używanych przez bramę, i przypnij powyższą politykę do kont AWS. Inaczej jedno wdrożenie Global Standard utworzone do szybkiego testu albo programista wywołujący Bedrock bezpośrednio z profilem globalnym obejdzie wszystko, co opisane wyżej.

6. 6

   Sprawdzaj to regularnie

   Raz w miesiącu wypisz wszystkie wdrożenia z ich typem w zasobach Azure za bramą oraz używane modele i profile Bedrock, a potem porównaj to z listą modeli. Rozbieżność to pierwszy sygnał, że ktoś dodał ścieżkę poza UE.

model_list:
  # Azure OpenAI: Data Zone Standard deployment in an EU resource
  - model_name: gpt-eu
    litellm_params:
      model: azure/<data-zone-eu-deployment-name>
      api_base: https://<eu-resource-name>.openai.azure.com/
      api_key: os.environ/AZURE_EU_API_KEY
      api_version: "<api-version>"
  # Amazon Bedrock: EU geographic inference profile, called from Frankfurt
  - model_name: claude-eu
    litellm_params:
      model: bedrock/<eu-profile-id>
      aws_region_name: eu-central-1
# No wildcard entries such as azure/* or bedrock/*
# No fallbacks to models outside this list

curl -X POST "$LITELLM_URL/team/new" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"team_alias": "claims", "models": ["gpt-eu", "claude-eu"]}'

curl -X POST "$LITELLM_URL/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "<team-id-from-the-response>"}'

Krótka lista kontrolna dla inspektora ochrony danych

Inspektor ochrony danych potrzebuje stanu umów, listy podmiotów przetwarzających i wykazu wszystkich miejsc, w których przechowywane są prompty. Wszystko to mogą przygotować inżynierowie:

• Umowa powierzenia przetwarzania (DPA): dla modeli sprzedawanych przez Azure Microsoft odsyła do swojego Products and Services Data Protection Addendum, Claude w Foundry podlega data processing addendum Anthropic, a w Bedrock sprawdź warunki przetwarzania danych w twojej umowie z AWS. Art. 28 ust. 3 RODO wymaga umowy, która określa przedmiot, czas trwania, charakter i cel przetwarzania.
• Dalsze podmioty przetwarzające: art. 28 ust. 2 RODO wymaga twojej zgody, zanim podmiot przetwarzający zaangażuje kolejny. Zapisz, kto co przetwarza: Microsoft lub AWS w przypadku usługi modelu, a w Foundry Anthropic jako niezależny podmiot przetwarzający dla Claude.
• Wykaz wdrożeń: każde wdrożenie i profil używane przez bramę, z typem wdrożenia lub ID profilu, regionem i datą ostatniej kontroli.
• Abuse monitoring i przechowywanie: w Azure, gdzie jest magazyn, że weryfikatorzy dla wdrożeń w EOG pracują w EOG i czy złożyłeś wniosek o modified abuse monitoring. W Bedrock, które z twoich modeli wymagają przechowywania i jaki tryb przechowywania ustawiono w każdym regionie.
• Funkcje przechowujące treści: czy ktoś używa Responses API, wątków Assistants, stored completions, zadań wsadowych lub przesłanych plików, które z założenia przechowują treści.
• Twoje własne logi: logi zapytań bramy, ślady i logowanie w chmurze często zawierają pełne prompty i za nie odpowiadasz sam. Świadomie ustal okres ich przechowywania. Opisujemy to w przewodniku o przechowywaniu śladów AI.
• Termin przeglądu: strony dostawców, na których opiera się ten przewodnik, były aktualizowane między majem a wrześniem 2026. Sprawdzaj poniższe źródła co najmniej raz na kwartał i przy każdym nowym modelu.

Jeśli lista kontrolna pokaże, że potrzebne modele nie są dostępne w UE, albo kwestia CLOUD Act wyklucza amerykańskich dostawców dla części danych, zostaje wdrożenie tylko w UE na twoim własnym koncie chmurowym z mniejszym wyborem modeli albo modele na własnych serwerach dla tych danych.

AI na własnym koncie AWS lub AzureBrama LiteLLM: wdrożenie i utrzymanieAI on-premise na własnych serwerach