AI na AWS zgodne z GDPR i AI Act

Uruchomienie modelu w chmurze nie daje automatycznie zgodności z GDPR ani AI Act. AWS zabezpiecza infrastrukturę, ale organizacja nadal odpowiada za zakres danych, konfigurację usług, uprawnienia, retencję, monitoring i sposób użycia wyniku. „Private by design” jest zestawem decyzji architektonicznych i dowodów, nie właściwością konta AWS.

Ten przegląd opiera się na oficjalnej dokumentacji AWS, sprawdzonej 30 lipca 2026 r. Dostępność usług i funkcji zmienia się, dlatego przed wdrożeniem trzeba ponownie sprawdzić wybrany region, model i profil inferencji.

Architektura referencyjna

Typowy system ma kilka warstw:

Wejście przez API Gateway z uwierzytelnieniem, limitami i walidacją.
Dokumenty w S3, szyfrowane i wersjonowane, z ograniczonym dostępem.
Ekstrakcja przez Textract, jeśli źródłem są skany lub formularze.
Retrieval i metadane, np. indeks wiedzy oraz DynamoDB dla stanu procesu.
Inferencja w Amazon Bedrock z jawnie wybranym modelem i sposobem routingu.
Guardrails jako dodatkowa kontrola wejścia i wyjścia — nie zamiennik autoryzacji, ewaluacji ani nadzoru człowieka.
CloudWatch, CloudTrail i opcjonalne logi wywołań modelu, skonfigurowane tak, aby dowód nie stał się niekontrolowaną kopią danych wrażliwych.

Nie zakładaj, że wspieranie Bedrock w regionie oznacza dostępność każdego modelu, Guardrails, Textract i wszystkich funkcji pomocniczych. Oficjalne tabele regionów należy sprawdzić osobno dla Amazon Bedrock, Amazon Textract, Amazon S3, Amazon DynamoDB, Amazon CloudWatch i Amazon API Gateway.

Region danych: single-region to nie cross-region

Amazon Bedrock obsługuje inferencję w regionie oraz profile cross-region. Dokumentacja cross-region inference rozróżnia:

profil geograficzny — żądanie może trafić do komercyjnego regionu AWS w określonej geografii, np. UE;
profil globalny — żądanie może zostać obsłużone w dowolnym wspieranym komercyjnym regionie AWS.

„EU geographic” nie znaczy „jeden wskazany region”. Jeśli polityka wymaga przetwarzania wyłącznie w eu-central-1, nie używaj profilu cross-region bez udokumentowanego wyjątku. Wywołuj model dostępny w tym regionie i sprawdź, czy cały łańcuch — OCR, storage, retrieval, logi i backup — spełnia tę samą regułę. Przy profilu cross-region polityki SCP muszą dopuszczać regiony docelowe wskazane przez profil; inaczej wywołania mogą nie działać.

Co Bedrock robi z promptami — i czego to nie rozwiązuje

AWS podaje w dokumentacji ochrony danych Bedrock, że wejścia i wyjścia nie są używane do trenowania ani ulepszania bazowych modeli. Nie oznacza to jednak automatycznie zerowej retencji ani braku udostępnienia danych dostawcy dla każdego modelu. Aktualna dokumentacja retencji rozróżnia tryby zależne od modelu i konfiguracji: none, default, inherit oraz provider_data_share. Tryb none oznacza brak trwałego zapisu żądania i odpowiedzi przez AWS oraz brak przekazania ich dostawcy; default stosuje politykę danego modelu, a provider_data_share dopuszcza retencję i przekazanie danych dostawcy. Przed wdrożeniem trzeba sprawdzić allowed_modes konkretnego modelu i efektywną konfigurację projektu lub konta. Sam parametr API store=false nie jest dowodem zero data retention. Dokumentacja abuse detection opisuje ponadto wyjątki dla treści oznaczonych przez mechanizmy bezpieczeństwa.

Niezależnie od trybu Bedrock Twoja aplikacja może zapisać treść w S3, DynamoDB, indeksie wektorowym, CloudWatch, narzędziu APM, historii czatu albo systemie obsługi zgłoszeń. Osobną funkcją jest model invocation logging: jest domyślnie wyłączone, a po włączeniu może zapisywać pełne żądania, odpowiedzi i metadane do CloudWatch Logs lub S3. Zanim je włączysz, określ zakres, dostęp, retencję, szyfrowanie i redakcję danych. „Bedrock nie trenuje na promptach” nie oznacza „nigdzie nie mamy kopii promptu”.

IAM, PrivateLink i KMS: trzy różne kontrole

IAM ogranicza, kto i z jakiej roli może wywołać model, odczytać dokument lub zmienić konfigurację. To klient definiuje role, polityki najmniejszych uprawnień, separację środowisk i procedurę odebrania dostępu.
VPC endpoints przez AWS PrivateLink pozwalają łączyć się z endpointem Bedrock bez wystawiania ruchu przez publiczny internet. Oficjalna instrukcja: Protect your data using Amazon VPC and AWS PrivateLink. Prywatna ścieżka sieciowa nie zmienia jednak zasad routingu wybranego profilu cross-region i nie zastępuje autoryzacji.
KMS i szyfrowanie usług chronią dane w spoczynku. Klucz zarządzany przez klienta może zwiększyć kontrolę nad polityką i audytem, ale wymaga poprawnej konfiguracji uprawnień, rotacji, backupu i reakcji na awarie. Nie szyfruje automatycznie danych skopiowanych poza objęte nim zasoby.

CloudTrail nie jest logiem treści modelu

CloudTrail dla Amazon Bedrock rejestruje działania API i pozwala ustalić m.in. kto, kiedy i z jakiego adresu wykonał operację. Historia zdarzeń jest dostępna dla zdarzeń zarządzających, ale wywołania runtime są zdarzeniami danych o dużym wolumenie i nie są logowane standardowo bez odpowiedniej konfiguracji. CloudTrail nie powinien być opisywany jako automatyczny zapis pełnego promptu i odpowiedzi.

Jeśli potrzebujesz treści do kontroli jakości, włączasz osobno invocation logging lub zapisujesz ograniczony artefakt w aplikacji. Najbezpieczniej logować minimum: identyfikator żądania, użytkownika lub rolę, wersję systemu i modelu, identyfikatory źródeł, wynik polityki, eskalację i decyzję człowieka. Pełna treść trafia do logu tylko wtedy, gdy ma uzasadniony cel, podstawę, ograniczony dostęp i termin usunięcia.

Model współodpowiedzialności w praktyce

AWS Shared Responsibility Model oddziela bezpieczeństwo chmury od bezpieczeństwa w chmurze. Dla systemu AI przekłada się to na następujący podział:

Obszar	AWS	Klient wdrażający AI
Fizyczna infrastruktura, hosty i warstwa zarządzanej usługi	obsługa i ochrona infrastruktury chmurowej	weryfikacja wymagań i dokumentów dostawcy
Wybór regionu i profilu inferencji	udostępnienie regionów, modeli i mechanizmu routingu	wybór zgodny z polityką danych oraz test całego łańcucha
IAM i dostęp do danych	mechanizmy IAM i logowanie operacji	role, polityki, segregacja obowiązków, recertyfikacja dostępów
Dane wejściowe i baza wiedzy	zabezpieczenia usług bazowych oraz obsługiwane tryby retencji modelu	minimalizacja, podstawa przetwarzania, jakość, wersje, wybór modelu, `allowed_modes` i efektywny tryb retencji
Logi	CloudTrail, CloudWatch, S3 i invocation logging jako funkcje	decyzja co logować, redakcja, retencja, dostęp i monitoring
Jakość odpowiedzi	wykonanie wybranego modelu i funkcji Guardrails	golden set, progi, ewaluacje, nadzór człowieka i reakcja na błędy
AI Act i GDPR	dokumenty zgodności usług AWS	klasyfikacja użycia, role prawne, DPIA/LIA gdy potrzebne, informowanie osób i dowody

Guardrails są warstwą, nie polityką AI

Guardrails for Amazon Bedrock pozwalają stosować m.in. filtry treści, tematy blokowane i ochronę informacji wrażliwych. Trzeba je wersjonować i testować na własnych przypadkach. Guardrail nie ustala, kto może zobaczyć dokument, czy cytat jest poprawny ani czy decyzja biznesowa wymaga akceptacji. Te różnice szerzej opisujemy w tekście Guardrails to nie polityka AI.

Minimalny Evidence Pack przed produkcją

Przed decyzją go/no-go zachowaj:

diagram przepływu danych z regionami i usługami;
listę modeli, profili inferencji i regionów docelowych;
macierz IAM oraz wyniki testów dostępu negatywnego;
konfigurację logów wraz z retencją i redakcją;
rejestr źródeł, wersji i właścicieli danych;
golden set, progi jakości, wyniki i błędy krytyczne;
reguły human approval, rollbacku i obsługi incydentu;
wersje Guardrails i wyniki testów obejścia;
decyzję właściciela procesu z datą kolejnego przeglądu.

Taki pakiet pokazuje, że kontrola działa w konkretnej konfiguracji. Certyfikat chmury ani lista usług nie dowodzą jeszcze zgodności wdrożenia.

Jak zaczynamy

Zaczynamy od przepływu danych i decyzji, nie od deklaracji „wszystko zostaje w AWS”. Podczas audytu gotowości AI ustalamy regiony, źródła, uprawnienia, retencję, klasyfikację użycia oraz metryki odbiorowe. Dopiero potem budujemy ograniczony PoC i sprawdzamy, czy architektura przechodzi zapisane bramki.