RODO i AI Act w jednym SaaS

To case study z prawdziwego zlecenia z polską firmą B2B SaaS liczącą około 180 osób. Produkt to wewnętrzny asystent wiedzy używany przez klientów mid-market z sektora usług finansowych (banki, brokerzy, firmy faktoringowe) do przeszukiwania ich własnych dokumentów polityk, kontraktów i procedur. Klient poprosił o pomoc w implementacji dwóch konkretnych obowiązków: art. 32 RODO (bezpieczeństwo przetwarzania) i art. 9 AI Actu (zarządzanie ryzykiem i governance danych dla systemów AI wysokiego ryzyka). Trzy inne obowiązki w zakresie (art. 10 governance danych, art. 12 logowanie, art. 14 nadzór człowieka) zostały dostarczone w ramach tego samego programu. Post skupia się na 32 i 9, bo to właśnie te artykuły klient miał największe trudności z przełożeniem na pracę inżynierską.

Pozycja startowa

Produkt działał od 14 miesięcy. Inferencja szła przez API dużego modelu językowego hostowanego w USA. Dokumenty klientów opuszczały ich infrastrukturę, były tokenizowane na serwerach w regionie USA, zwracane jako completiony i nie były logowane w warstwie storage klienta. Klient miał Data Processing Agreement z vendorem modelu - architektonicznie poprawne (brzmienie lustrzane ze standardowymi klauzulami umownymi UE), ale technicznie nieegzekwowalne: klient nie miał sposobu na wykazanie, że ścieżka inferencji nie zawierała metadanych poza tym, co pokazywał dashboard vendora. Dwie rzeczy były prawdziwe jednocześnie. DPA istniało, więc na papierze system był zgodny. Architektura nie pasowała do DPA, więc w praktyce nie był.

Co faktycznie wymaga art. 32 RODO

Art. 32 RODO to artykuł o bezpieczeństwie przetwarzania. Wymienia "odpowiednie środki techniczne i organizacyjne": pseudonimizację i szyfrowanie danych osobowych; zdolność zapewnienia ciągłej poufności, integralności, dostępności i odporności systemów i usług przetwarzania; zdolność przywrócenia dostępności i dostępu do danych osobowych w odpowiednim czasie w przypadku incydentu; proces regularnego testowania, oceniania i ewaluacji skuteczności tych środków.

Artykuł ma zasadniczo charakter zasad, nie reguł. W audycie to właśnie problem: każdy audytor czyta go trochę inaczej. W tym zleceniu zmapowaliśmy art. 32 do czterech kontrolek inżynierskich: (1) szyfrowanie at rest (AES-256) i in transit (TLS 1.3), z 12-miesięczną kadencją rotacji kluczy i krótszą dla powierzchni wysokiego wpływu; (2) pseudonimizacja PII zanim dotrze do modelu, z odwracalną tablicą mapowań przechowywaną osobno od kontekstu modelu i dostępem kontrolowanym przez IAM klienta; (3) udokumentowany runbook incydentowy z RTO i RPO na warstwie AI, testowany kwartalnie ćwiczeniem tabletop obejmującym warstwę serwującą model, nie tylko warstwę aplikacji; (4) roczny zewnętrzny test penetracyjny z dedykowanym zakresem powierzchni AI (prompt injection, retrieval poisoning, próby eksfiltracji modelu). Pseudonimizacja jest strukturalna, nie kontrolką: jeśli PII dociera do modelu surowe, możesz mieć DPA na miejscu i dalej nie spełniać art. 32.

Co faktycznie wymaga art. 9 AI Actu

Art. 9 AI Actu siedzi w Rozdziale III, Sekcji 2, obok art. 10-15. To artykuł o zarządzaniu ryzykiem dla systemów AI wysokiego ryzyka. Art. 9(1) wymaga, aby system zarządzania ryzykiem był "ustanowiony, wdrożony, udokumentowany i utrzymywany" jako "proces ciągły i iteracyjny" przez cały cykl życia systemu. Art. 9(2) wymaga identyfikacji i analizy "znanych i dających się rozsądnie przewidzieć ryzyk" dla zdrowia, bezpieczeństwa i praw podstawowych. Art. 9(3) wymaga szacowania i oceny ryzyk, które "mogą się pojawić" gdy system jest używany zgodnie z przeznaczeniem i w warunkach dającego się rozsądnie przewidzieć niewłaściwego użycia. Art. 9(5) wymaga testowania "aby zapewnić, że system działa spójnie i że jest zgodny z wymaganiami określonymi w niniejszym Rozdziale." Kombinacja jest nietypowa w porównaniu z RODO: udokumentowany proces ORAZ bieżące testy ORAZ założenie, że niewłaściwe użycie nastąpi. Art. 9 faktycznie tworzy obowiązek testowania trybów awarii, które jeszcze nie zostały zaobserwowane.

Jak wyglądał program wdrożeniowy

Program biegł cztery miesiące przez cztery sprinty.

Sprint 1 - rejestr ryzyk i katalog nadużyć. Zbudowaliśmy rejestr ryzyk z art. 9 jako dokument YAML w repozytorium, wersjonowany i recenzowalny. Pięć kategorii (ekspozycja danych, zachowanie modelu, niezgodność regulacyjna, naruszenie kontraktowe, awaria stron trzecich) i 23 ryzyka w zbudowanym systemie. Każde ryzyko miało likelihood, impact, wynik rezydualny po istniejących kontrolkach i decyzję: mityguj, akceptuj, transferuj, unikaj. Katalog nadużyć wymagał trzech jednogodzinnych warsztatów z zespołami customer-facing i product, przechodzących przez to, co klient mógłby spróbować, czego nie zamierzaliśmy. Katalog skończył na 17 udokumentowanych przypadkach nadużyć, w tym prompt injection przez dokumenty klientów, retrieval danych treningowych przez craftowane sesje i bypass instrukcji użycia.

Sprint 2 - mapowanie governance danych z art. 10 i pseudonimizacja z art. 32. Inwentarz danych został odbudowany. Pola danych osobowych otagowano podstawą przetwarzania (kontrakt, prawnie uzasadniony interes, zgoda). Pola, które nie musiały docierać do modelu, filtrowano na granicy. Pola, które musiały być referencyjne, były pseudonimizowane przed przekroczeniem granicy. To mapowanie było artefaktem kontraktowym dla relacji z klientem na gruncie art. 28 RODO: bez niego processor nie może wykazać obowiązków z art. 32; z nim klient może podpisać.

Sprint 3 - zmiana ścieżki inferencji. Inferencja przeniosła się do prywatnego deploymentu modelu open-weights (oparty na Mistral, 22B parametrów, AWQ-kwantyzowany) na dedykowanym sprzęcie klienta w kolokacji w kraju członkowskim UE. DPA z poprzednim vendorem zostało w aktach jako rekord historyczny, ale ścieżka inferencji była całkowicie lokalna. To strukturalna zmiana z art. 9: ścieżka inferencji hostowana w USA może być broniona w DPA; nie może spełnić testowania z art. 9(5) w pełni zamknięty sposób, bo środowisko nie jest pod kontrolą operatora.

Sprint 4 - logowanie, testy, model card. Logowanie z art. 12 zostało wdrożone jako podpisane zdarzenie JSON na każde wywołanie inferencji, 12-miesięczna retencja. Testowanie z art. 15 podpięte do CI z held-out fixtures z zatwierdzonych przez klienta seedów, uruchamiane przy każdej zmianie modelu lub retrieval. Model card zostało napisane, zrecenzowane przez compliance officera klienta i opublikowane w dokumentacji deployera.

Co klient z tego wyniósł

Udokumentowany system zarządzania ryzykiem, który przechodzi cykl zakupowy (rejestr ryzyk i katalog nadużyć stały się odpowiedzią na pytanie "jak radzicie sobie z bezpieczeństwem AI?" w trzech kolejnych RFP; koszt budowy artefaktu był niższy niż jeden stracony deal mid-market). Architektura modelu, która nie zależy już od ścieżki inferencji w kraju trzecim - fakt strukturalny, nie claim marketingowy, dający się obronić przed każdym unijnym regulatorem. Audytowalna ocena zgodności z Rozdziałem III AI Actu, z dokumentacją techniczną dla art. 9, 10, 12, 14 i 15 w jednym repozytorium, zrecenzowaną z zewnętrznym radcą prawnym. Czy klient wybiera self-assessment z art. 43(1), czy ocenę zgodności stron trzecich, zależy od klasyfikacji systemu w AI Act, ale ten sam zestaw dokumentacji służy obu ścieżkom.

Co nie zadziałało

Trzy rzeczy, warte wymienienia, bo wracają. Rejestr ryzyk jako dokument jednorazowy. Pierwsza wersja była napisana w sprincie 1 i traktowana jako skończona; nowa wersja modelu unieważniła trzy ryzyka sześć tygodni później. Fix: prze-uruchamiaj rejestr przy każdej zmianie modelu, retrieval lub poważnej zmianie schemy. Teraz część CI. Mapowanie art. 32 do jednej kontrolki. Trzy zespoły chciały twierdzić, że pseudonimizacja spełnia art. 32. Nie spełnia; artykuł to właściwość systemu. Pseudonimizacja komponuje się z szyfrowaniem, odpornością i testowaniem. Traktowanie art. 9 jako papierowego ćwiczenia. Testowanie z art. 9(5) było wąskim gardłem sprintu 4. Pierwsza próba użyła benchmarku marketingowego i została odrzucona. Odbudowana przeciwko held-out testowi z udokumentowanymi seedami, co wsparło ocenę zgodności. Trzy tygodnie, których nie budżetowaliśmy.

Co to oznacza dla małego SaaS

Trzy zasady przenoszą się z tego przypadku na szerszą populację regulowanych polskich SaaS. Art. 32 jest strukturalny. Pseudonimizacja, szyfrowanie, odporność i testy komponują się w jedną właściwość - jeśli twoja warstwa AI nie spełnia wszystkich czterech, audyt zawodzi na najsłabszym punkcie. Art. 9 jest procesem. Rejestr ryzyk i testy to bieżące obowiązki; budżetuj na nie i włóż je w CI. Architektura jest śladem audytowym. Dla art. 9(5) i art. 15 diagram wdrożenia i raporty z testów są dowodem. Jeśli te dokumenty nie są w repozytorium pod twoim zarządzaniem zmianą, obrona audytowa zawodzi zanim się zacznie. Termin egzekwowania AI Actu dla systemów wysokiego ryzyka to 2 sierpnia 2026; powyższy program zajmuje trzy do sześciu miesięcy od czystej kartki. ArtCode Software prowadzi ten sam czteromiesięczny program z regulowanymi klientami MŚP dziś. Jeśli chcesz fixed-scope diagnostykę tego, gdzie twój system stoi w zakresie art. 32 RODO i art. 9 AI Actu, AI Readiness Audit to dwudniowe zlecenie, które produkuje tę mapę. Jeśli potrzebujesz programu wdrożeniowego osadzonego w twoim zespole, Fractional AI Architect Retainer działa jeden dzień w tygodniu, aż dokumentacja daje się recenzować.