AI na AWS a compliance — gdzie naprawdę mieszkają Twoje dane

Zgodność AI nie zaczyna się od polityki — zaczyna się od architektury. Gdy AI działa w Twoim koncie AWS, dane zostają w wybranym regionie (np. UE), w izolowanej sieci (VPC), zaszyfrowane Twoim kluczem (KMS), z pełnym śladem dostępu (IAM, CloudTrail). Audytor nie pyta „czy macie politykę” — pyta „gdzie są dane i kto je widział”. Architektura, która domyślnie odpowiada na to pytanie, robi połowę pracy compliance za Ciebie.

Publiczny chatbot wysyła Twoje dane „gdzieś”. To pierwsza rzecz, która wywraca audyt RODO i AI Act. Budowanie AI na AWS, w Twoim koncie, odwraca to pytanie: dane nie wychodzą, a Ty masz dowód, gdzie są.

Dane zostają u Ciebie

W Amazon Bedrock dane wejściowe i wyjściowe nie są używane do trenowania modeli bazowych ani udostępniane dostawcom modeli, a przetwarzanie zostaje w regionie, w którym wywołano API. Dla firmy to różnica między „ufamy, że dostawca nie użyje naszych danych” a „nasze dane nie wychodzą z naszego konta”. To pierwsza rzecz, którą warto umieć wykazać przed regulatorem.

Cztery filary, o które pyta audytor

Rezydencja danych. Region UE (np. eu-central-1) — wiesz i wykazujesz, gdzie fizycznie są dane. RODO i wymogi sektorowe tego oczekują.
Izolacja sieci (VPC). AI działa w prywatnej sieci, bez wystawiania na publiczny internet — ruch przez VPC, nie przez otwarty endpoint.
Szyfrowanie i kontrola klucza (KMS). Dane szyfrowane w spoczynku i w tranzycie, kluczem, którym zarządzasz Ty — nie „gdzieś w chmurze dostawcy”.
Tożsamość i ślad audytowy (IAM, CloudTrail). Kto, kiedy i do czego miał dostęp — zapisane. To dokładnie to, czego AI Act oczekuje od systemów wysokiego ryzyka: logi i rozliczalność.

„AWS-native to lock-in”? To wybór architektoniczny, nie religia

Podejście „vendor-agnostic” kupuje elastyczność, ale płacisz za nią powierzchnią: więcej dostawców to więcej miejsc, w których mieszkają dane, więcej śladów audytowych do zszycia i więcej umów do sprawdzenia. AWS-native daje głębszą integrację i jeden, spójny ślad audytowy — łatwiejszy do wykazania przed regulatorem. Żadne podejście nie jest z założenia lepsze; my wybieramy AWS-native, bo dla zgodności jeden audytowalny obwód bije rozproszenie. Lock-in to mit: dane i logika pozostają Twoje, a eksport jest możliwy.

Co to daje przy AI Act

System wysokiego ryzyka wymaga rejestrowania zdarzeń, nadzoru człowieka i dokumentacji technicznej. Architektura, która domyślnie loguje (CloudTrail), izoluje (VPC) i szyfruje pod Twoim kluczem (KMS), nie spełnia AI Act sama z siebie — ale daje fundament, na którym te obowiązki da się wykazać, zamiast dorabiać je po fakcie.

W skrócie

Compliance AI to najpierw architektura, potem polityka. AI w Twoim koncie AWS = dane w wybranym regionie, izolacja VPC, szyfrowanie kluczem KMS, audyt IAM/CloudTrail, dane poza treningiem modeli. Audytorowi pokazujesz dowód, nie deklarację.

Co dalej

Jak budujemy RAG na AWS, z danymi w Twoim koncie, opisujemy na stronie RAG / bazy wiedzy. Architekturę, klasyfikację ryzyka i utrzymanie zgodności w czasie domykamy w audycie i opiece ciągłej. Jeśli chcesz wiedzieć, czy Twój obecny system to udźwignie — zacznij od audytu zgodności z AI Act.