Pytanie, które pada najczęściej, brzmi „czy RODO pozwala nam wdrożyć AI”. Jest źle postawione, bo sugeruje, że gdzieś istnieje przepis odnoszący się do modeli językowych. Nie istnieje. RODO dotyczy przetwarzania danych osobowych i obowiązuje tak samo w arkuszu kalkulacyjnym, w systemie CRM i w integracji z modelem. To, co zmienia model językowy, to nie reżim prawny, tylko liczba miejsc, w których dane mogą wypłynąć poza zakres zaplanowany przez kogokolwiek.
Poniżej siedem rzeczy, które warto rozstrzygnąć przed budową, bo każda z nich jest po wdrożeniu kosztowna do zmiany. To opis strony technicznej i organizacyjnej, a nie porada prawna — ocena prawna należy do Twojego prawnika albo inspektora ochrony danych.
1. Ustal, czy w ogóle przetwarzasz dane osobowe
Brzmi trywialnie, a rozstrzyga o zakresie całego projektu — i bardzo często odpowiedź brzmi „nie”. Model klasyfikujący zgłoszenia serwisowe po treści usterki, model przewidujący awarie maszyn, asystent przeszukujący dokumentację techniczną: żaden z nich nie musi zobaczyć ani jednej danej osobowej, o ile zadbano o to na wejściu.
Warto sprawdzić to na konkretach, nie na deklaracji. Weź dziesięć rzeczywistych zapytań, które system miałby obsłużyć, i przeczytaj je linijka po linijce. Zwykle okazuje się jedno z dwojga: albo danych osobowych naprawdę nie ma i projekt jest znacznie prostszy, niż zakładano, albo są w miejscach, o których nikt nie pamiętał — w stopce maila, w nazwie pliku, w polu z uwagami.
2. Rozstrzygnij podstawę prawną, zanim cokolwiek wyślesz
Podstawę prawną ustala się przed przetwarzaniem, nie po nim, a ustalona po fakcie nie naprawia niczego wstecz. Jest to jeden z częstszych błędów przy pilotażach: dane trafiają do narzędzia na próbę, a pytanie o podstawę pojawia się dopiero wtedy, gdy pilotaż ma stać się produkcją.
Zgoda bywa odruchowym wyborem i zwykle nie jest najlepszym. Jest odwoływalna w każdej chwili, a w relacji pracodawca–pracownik trudno wykazać jej dobrowolność. W procesach biznesowych częściej właściwe okazują się wykonanie umowy albo prawnie uzasadniony interes. Przy pierwszej z tych podstaw warto pamiętać o warunku, który bywa pomijany: przetwarzanie musi być niezbędne do wykonania umowy zawartej z samą osobą, której dane dotyczą — a w procesach B2B osoba ta bywa kimś zupełnie innym niż Twój kontrahent. Druga wymaga udokumentowanego testu równowagi, który trzeba wykonać, a nie założyć.
Osobną sprawą są dane szczególnych kategorii — o zdrowiu, przekonaniach czy przynależności związkowej. Jeżeli mogą pojawić się w tym, co trafia do modelu, choćby przypadkiem w opisie zgłoszenia, sama podstawa z artykułu 6 nie wystarczy: potrzebna jest wtedy dodatkowo przesłanka z artykułu 9, a ich katalog jest wyraźnie węższy. Warto sprawdzić to na tych samych dziesięciu zapytaniach co w punkcie pierwszym.
Istotne jest też to, że dodanie modelu do procesu, w którym dane już przetwarzasz, nie jest automatycznie objęte dotychczasową podstawą. Jeżeli zmienia się cel albo zakres przetwarzania, zmiana wymaga osobnej oceny.
3. Wyślij mniej
To najskuteczniejsze zabezpieczenie w całym projekcie i jednocześnie najtańsze: dane, których nie wysłano, nie wymagają po stronie dostawcy żadnych gwarancji umownych, żadnego regionu przetwarzania ani żadnej procedury usuwania.
W praktyce oznacza to warstwę pośrednią, która decyduje, co opuszcza Twój system: które pola są naprawdę potrzebne, co da się pominąć, a co zastąpić identyfikatorem. Model rozstrzygający, czy reklamacja jest zasadna, nie potrzebuje nazwiska klienta — potrzebuje treści reklamacji i historii zamówienia.
Uwaga na pojęcia: zastąpienie nazwiska identyfikatorem to pseudonimizacja, a dane spseudonimizowane nadal są danymi osobowymi. Jest to bardzo dobra praktyka, ale nie wyprowadza projektu spod RODO — robi to dopiero rzeczywista anonimizacja, czyli taka, po której powiązania z osobą nie da się odtworzyć rozsądnym nakładem środków.
4. Uporządkuj role: kto jest administratorem, a kto przetwarza
W typowym wdrożeniu występują trzy podmioty i trzy różne role. Administratorem jesteś Ty, bo to Twoje dane i Twoje cele przetwarzania. Wykonawca budujący system działa jako podmiot przetwarzający, na Twoje udokumentowane polecenie.
Rola dostawcy modelu nie jest natomiast przesądzona z góry i nie rozstrzyga jej sama umowa. W RODO rolę wyznacza to, kto dla danej operacji decyduje o celach i sposobach przetwarzania — umowa powinna to odzwierciedlać, a nie ustanawiać. W praktyce wygląda to tak: w zakresie zapytań wykonywanych na Twoje polecenie dostawca działa jako podmiot przetwarzający — dalszy, jeżeli angażuje go wykonawca, i wtedy potrzebna jest Twoja zgoda na podpowierzenie, albo bezpośrednio Twój, jeżeli umowę zawierasz z nim sam. W zakresie, w jakim wykorzystuje te same dane do własnych celów — co bywa regułą w wariantach konsumenckich — jest w tej części odrębnym administratorem.
Te dwie role potrafią występować jednocześnie: ta sama usługa bywa podmiotem przetwarzającym dla jednej operacji i administratorem dla drugiej. Dlatego rolę ustala się osobno dla każdej operacji, a nie raz dla całego dostawcy.
Konsekwencje są praktyczne, nie formalne. To administrator odpowiada za podstawę prawną, za obowiązek informacyjny wobec osób i za rejestr czynności przetwarzania — również wtedy, gdy zawiedzie podmiot, któremu powierzył dane. Dlatego wybór dostawcy modelu nigdy nie jest wyłącznie decyzją techniczną.
Praktyczny wniosek dla harmonogramu, z jednym zastrzeżeniem. Umowa powierzenia jest wymagana wtedy, gdy ktoś przetwarza dane osobowe w Twoim imieniu — jeżeli pilotaż obchodzi się bez danych osobowych, jak w punkcie pierwszym, nie jest w tym miejscu potrzebna wcale. Jeżeli jednak dane osobowe w grę wchodzą, umowa jest warunkiem startu, a nie dokumentem domykanym przy odbiorze: podpisana po uruchomieniu pilotażu znaczy tyle, że pilotaż działał bez niej.
5. Zdecyduj o regionie i o trenowaniu — świadomie, nie domyślnie
Dwie rzeczy trzeba sprawdzić w warunkach konkretnej usługi, bo w obu domyślne ustawienie bywa nie tym, którego się spodziewasz.
Pierwsza to region przetwarzania. Główni dostawcy modeli oferują dziś przetwarzanie w regionach europejskich, ale nie w każdym z nich jest to wartość domyślna, a zmiana regionu po wdrożeniu bywa równoznaczna z migracją. Jeżeli dopuszczasz transfer poza EOG, potrzebujesz podstawy tego transferu — i jest to ustalenie na start, nie na później. Sam europejski region nie zamyka jednak tematu: jeżeli do danych może sięgnąć wsparcie techniczne albo podwykonawca spoza EOG, transfer i tak występuje, mimo że dane fizycznie leżą w Europie. Pytaj więc nie tylko o to, gdzie dane są przechowywane, ale też o to, skąd są dostępne.
Druga to wykorzystanie treści do trenowania modelu. Biznesowe warianty usług dużych dostawców standardowo je wyłączają, konsumenckie bywają odwrotne — i to jest realna różnica między korzystaniem z tego samego modelu przez konto firmowe a przez prywatne konto pracownika. Który wariant obowiązuje w Twoim projekcie, powinno wynikać z warunków umownych, a nie z założenia.
6. Rozdziel RODO od AI Act, zamiast je mieszać
Te dwa reżimy trzeba spełnić równolegle i żaden nie zastępuje drugiego, a mylone bywają w obie strony.
Z RODO wynika ograniczenie decyzji podejmowanych wyłącznie automatycznie, o ile wywołują wobec osoby skutki prawne albo w podobny sposób istotnie na nią wpływają. Słowo „wyłącznie” jest tu decydujące: sam udział człowieka nie wystarczy, jeżeli sprowadza się do zatwierdzania podpowiedzi bez realnej możliwości jej zmiany.
Z AI Act wynika co innego. Jego obowiązki zależą od klasyfikacji systemu, a nie od wagi pojedynczej decyzji — i część z nich obowiązuje niezależnie od tego, czy w rozmowie w ogóle padają dane osobowe. Tak jest z obowiązkiem poinformowania człowieka, że rozmawia z systemem AI: dotyczy systemów przeznaczonych do bezpośredniej interakcji z osobą i nie stosuje się tam, gdzie jest to oczywiste z kontekstu, ale o danych osobowych nie mówi w ogóle. Co z tego wynika po stronie technicznej, opisaliśmy przy audycie gotowości na AI Act.
Najkrócej: RODO pyta, czyje dane przetwarzasz i na jakiej podstawie. AI Act pyta, czym jest zbudowany przez Ciebie system i w jakim kontekście działa. Można spełnić jedno i naruszyć drugie.
7. Zaprojektuj realizację praw osób, zanim ktoś z nich skorzysta
Ten punkt najczęściej odkłada się na koniec, a jest jedynym, którego po wdrożeniu nie da się dopisać tanio. Osoba, której dane dotyczą, może zażądać dostępu, sprostowania albo usunięcia — a odpowiedź zależy od tego, gdzie jej dane osiadły.
Jeżeli model jedynie przetworzył zapytanie i niczego nie zapamiętał, usunięcie sprowadza się do Twoich systemów oraz do logów: Twoich, warstwy pośredniej i dostawcy. Jest to wykonalne, o ile z góry wiadomo, co jest logowane i jak długo.
Jeżeli dane trafiły do indeksu wyszukiwania — jak w rozwiązaniach typu RAG — usunięcie jest jak najbardziej wykonalne, ale trzeba je zaprojektować: skasowanie fragmentów i przebudowa indeksu to osobna funkcja, a nie skutek uboczny usunięcia rekordu w systemie źródłowym. Inaczej jest ze zbiorem treningowym: danych, które weszły w wagi modelu, w praktyce nie da się z niego wyjąć — i to jest ten przypadek, do którego lepiej w ogóle nie dopuścić.
Stąd zasada projektowa, która rozwiązuje ten problem u źródła: dane osobowe zostają w Twoich systemach, a do modelu trafia możliwie wąski wycinek. Wtedy prawa osób realizuje się tam, gdzie realizowało się je zawsze, a integracja z modelem komplikuje to znacznie mniej — pod warunkiem że procedurą objęte są również logi, odpowiedzi modelu i indeksy zbudowane na ich podstawie.
Warto przy okazji rozstrzygnąć retencję logów zapytań. Bywają traktowane jako dane techniczne, a potrafią zawierać kompletne treści dokumentów — łącznie z tym, co warstwa pośrednia właśnie starannie odfiltrowała z zapytania do modelu.
Lista kontrolna przed startem
Zanim uruchomisz choćby pilotaż, przejdź przez sześć punktów. Zajmą jedno spotkanie, a oszczędzają rozmowy, które inaczej odbywają się później i w gorszych okolicznościach:
- Czy do modelu trafiają dane osobowe? Sprawdzone na dziesięciu rzeczywistych zapytaniach, nie założone.
- Jaka jest podstawa prawna i czy obejmuje również nowy cel, jeżeli cel się zmienia.
- Jaki dokładnie zakres pól opuszcza Twój system i co da się z niego jeszcze usunąć.
- Czy umowa powierzenia jest w ogóle potrzebna — a jeżeli tak, czy obejmuje układ z dostawcą modelu: zgodę na podpowierzenie, gdy angażuje go wykonawca, albo osobną umowę, gdy zawierasz ją sam.
- W jakim regionie działa usługa i czy warunki wykluczają trenowanie na Twoich treściach.
- Co jest logowane, jak długo i w jaki sposób zrealizujesz żądanie usunięcia danych.
Jeżeli na którykolwiek z tych punktów nie ma dziś odpowiedzi na piśmie, to jest właśnie zakres pierwszego etapu — a nie powód, żeby projektu nie robić.
Gdzie to wchodzi w harmonogram projektu
W praktyce te ustalenia zapadają w fazie audytu, razem z wyborem procesu i sprawdzeniem stanu danych, ponieważ wszystkie wpływają na to samo: na zakres. Jak taki projekt wygląda etap po etapie i co powstaje na każdym z nich, opisaliśmy na stronie wdrożenie AI w firmie.
Jeżeli natomiast interesuje Cię, jak te same pytania wyglądają od strony wykonawcy — którędy dokładnie przepływają dane i o co warto zapytać każdego dostawcę, nie tylko nas — zebraliśmy to w bezpieczeństwie danych i RODO.