Wdrażacie AI na firmowych danych. Czy ktoś zrobił ocenę skutków?

Dlaczego RODO jest tu wcześniej niż AI Act

AI Act porządkuje rynek według poziomu ryzyka systemu i zdecydowana większość wdrożeń w małej firmie trafia w nim do kategorii, w której obowiązki są lekkie: oznaczanie treści, przejrzystość wobec użytkownika, kompetencje osób obsługujących narzędzie. Rzeczy ważne, ale niekosztowne.

RODO nie pyta o poziom ryzyka systemu. Pyta o jedną rzecz: czy przetwarzacie dane osobowe. Jeśli do modelu trafia nazwisko klienta, treść jego maila, numer sprawy, nagranie rozmowy albo dokument z danymi pracownika — odpowiedź jest twierdząca, niezależnie od tego, jak prosty jest scenariusz i czy nazywacie to „pilotażem”.

Różnica jest praktyczna i warto ją rozumieć jako kolejność, a nie jako wybór. AI Act dochodzi na koniec projektu — przy dokumentacji, oznaczeniach i nadzorze. RODO decyduje na początku: o tym, jakie dane wolno w ogóle wysłać do modelu, na jakiej podstawie, do jakiego dostawcy i na jak długo. Odwrócenie tej kolejności oznacza, że zgodność dopina się do gotowego wdrożenia, a to najdroższy moment na zmianę architektury.

Druga różnica to egzekwowanie. Krajowy organ nadzoru nad AI dopiero zaczyna działać, a jego uprawnienia kontrolne i karne stają się skuteczne pod koniec października 2026. Organ ochrony danych działa od 2018 roku, ma rozpoznawalną praktykę decyzyjną i regularnie karze również małe podmioty. Przy ocenie ryzyka wdrożenia to ta druga ścieżka jest dziś bardziej konkretna.

Pięć miejsc, w których dane osobowe wchodzą do wdrożenia AI

Większość firm ma intuicję, że „gdzieś tam” są dane osobowe, ale nie potrafi wskazać gdzie dokładnie — a bez tego nie da się ani ocenić ryzyka, ani odpowiedzieć na wniosek osoby, której dane dotyczą. W praktyce wdrożenie ma pięć wejść i każde trzeba rozpatrzyć osobno.

• Prompt, czyli to, co użytkownik wpisuje. Najbardziej niedoszacowane wejście. Pracownik wkleja fragment maila od klienta, żeby poprosić o odpowiedź — i w tej jednej czynności przekazuje dostawcy imię, adres, numer sprawy oraz kontekst sporu. To samo zjawisko opisaliśmy w tekście o shadow AI w firmie, z tą różnicą, że tam dzieje się bez wiedzy firmy, a tutaj z jej błogosławieństwem.
• Baza wiedzy, na której stoi asystent. Umowy, oferty, korespondencja, dokumentacja projektów, czasem akta pracownicze — jeśli indeksujecie „cały dysk”, zaindeksowaliście też dane, których nikt nie planował udostępniać. Mechanikę samego rozwiązania opisaliśmy w tekście o asystencie AI na dokumentach firmy; porządek w źródłach to osobny temat, który rozłożyliśmy w danych gotowych na AI.
• Wyjście modelu. Odpowiedź zawierająca dane osobowe to też przetwarzanie, a dodatkowo nowe ryzyko: model może przypisać komuś cechę, której nie ma. Nieprawdziwa informacja o konkretnej osobie nie jest tylko wpadką jakościową — jest przetwarzaniem danych niedokładnych, czego RODO wprost zakazuje i czego dotyczyły już skargi przeciwko dostawcom modeli.
• Logi i historia rozmów. Potrzebne do monitoringu jakości, wymagane w części scenariuszy przez AI Act, a jednocześnie najdłużej żyjąca kopia danych w całym wdrożeniu. Bardzo rzadko mają ustaloną retencję i prawie nigdy nie są uwzględnione w rejestrze czynności przetwarzania.
• Trening i dostrajanie modelu. Jeśli dostrajacie model na własnych danych, wchodzicie w scenariusz, z którego najtrudniej się wycofać: danych wtopionych w wagi modelu nie da się po prostu usunąć wiersz po wierszu. Europejski organ doradczy stwierdził w swojej opinii o modelach AI, że modele trenowane na danych osobowych nie mogą być z założenia uznawane za anonimowe — anonimowość trzeba wykazać dla konkretnego modelu, a to analiza techniczna, nie deklaracja w ofercie.

Ocena skutków: kiedy naprawdę trzeba i co w niej jest

Ocena skutków dla ochrony danych — DPIA — jest obowiązkowa, gdy przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób. Brzmi to ogólnie, dlatego polski organ nadzorczy publikuje wykaz rodzajów operacji, które taki obowiązek rodzą, i aktualizuje go o uwagi organu europejskiego. Wykaz zawiera kilkanaście kategorii, a reguła praktyczna jest taka: jeśli Wasze przetwarzanie spełnia co najmniej dwa kryteria z listy, oceny nie da się pominąć.

Wdrożenia AI wpadają w te kryteria częściej, niż się firmom wydaje, bo trafiają w kilka pozycji naraz: innowacyjne zastosowanie rozwiązań technologicznych, przetwarzanie na dużą skalę, ocena lub prognozowanie zachowań, a w części przypadków dane szczególnej kategorii. Analiza klientów z użyciem AI, scoring, systemy oceniające kandydatów czy pracowników, przetwarzanie danych biometrycznych — to przykłady, przy których dyskusji w zasadzie nie ma.

Są jednak wdrożenia, przy których obowiązku nie będzie i warto to uczciwie powiedzieć, bo nadmiarowa biurokracja zabija sensowne projekty równie skutecznie jak jej brak. Asystent odpowiadający na pytania o wewnętrzne procedury, generator opisów produktów, narzędzie porządkujące dokumentację techniczną — przy ograniczonym zakresie danych i braku automatycznych decyzji o ludziach zostaje analiza ryzyka, a nie pełna ocena skutków.

Sama ocena to w małej firmie dokument na kilka stron, nie projekt na kwartał. Musi opisywać: planowane operacje i ich cele, podstawę prawną, ocenę niezbędności i proporcjonalności, ryzyka dla osób oraz środki, które je ograniczają. Najwartościowszą częścią jest zwykle ta ostatnia — bo w trakcie jej pisania okazuje się, że połowę ryzyka da się zdjąć zmianą zakresu danych, a nie zakupem dodatkowego narzędzia.

Warto też znać mniej oczywisty mechanizm sankcji: brak wymaganej oceny skutków jest samodzielnym naruszeniem. Organ może ukarać za nią obok kary za samo nieprawidłowe przetwarzanie, co podnosi łączną kwotę. Ocena skutków nie jest więc tylko dokumentacją obronną — jej brak jest zarzutem.

Podstawa prawna, czyli pytanie, na które zgoda rzadko jest odpowiedzią

Odruch większości firm przy pytaniu o podstawę prawną brzmi: zbierzemy zgody. To zwykle najgorszy z możliwych wyborów i źródło problemów, które ujawniają się dopiero po kilku miesiącach.

Zgoda musi być dobrowolna, konkretna i odwoływalna w każdej chwili. Jeśli przetwarzanie dotyczy pracowników, dobrowolność jest wątpliwa z definicji — zależność służbowa psuje ten warunek. Jeśli dotyczy klientów, odwołanie zgody przez jedną osobę musi oznaczać wyłączenie przetwarzania jej danych, co w systemie opartym na zaindeksowanej bazie wiedzy wymaga mechanizmu, którego nikt nie zaprojektował. A zgoda na „korzystanie ze sztucznej inteligencji” jako taka nie jest konkretna i nie obroni się.

W praktyce wdrożenia w firmie opierają się na dwóch innych podstawach. Pierwsza to niezbędność do wykonania umowy — jeśli AI obsługuje proces, który i tak realizujecie dla klienta, przetwarzanie jego danych w tym procesie mieści się w umowie. Druga to uzasadniony interes administratora, najczęściej stosowana i najczęściej źle udokumentowana.

Uzasadniony interes nie jest hasłem, tylko testem z trzech kroków, który trzeba wykonać i zapisać: czy interes jest rzeczywisty i zgodny z prawem, czy przetwarzanie jest do niego niezbędne, i czy nie przeważają nad nim prawa oraz uzasadnione oczekiwania osób, których dane dotyczą. Ten ostatni krok przesądza najczęściej — klient wysyłający reklamację oczekuje, że ktoś ją przeczyta, ale nie zawsze oczekuje, że jej treść trafi do modelu zewnętrznego dostawcy. Stąd obowiązek informacyjny, a nie zgoda, jest tu właściwym narzędziem.

Osobna uwaga o stanie prawnym, bo rynek doradczy mocno go dziś upraszcza. Trwają prace nad unijnym pakietem upraszczającym przepisy cyfrowe, który miałby wprost wskazać uzasadniony interes jako podstawę przetwarzania danych przy rozwijaniu modeli AI. Organy ochrony danych w swojej wspólnej opinii z lutego 2026 uznały ten przepis za zbędny i wymagający wyjaśnień, a jednocześnie przypomniały, że test trzech kroków i tak trzeba będzie wykonać. Dla Waszego projektu wniosek jest prosty: nic się nie zmieniło i nie warto budować wdrożenia na zapowiedzi zmiany przepisów.

Dostawca modelu jest podmiotem przetwarzającym. Z wszystkimi konsekwencjami

Jeśli wysyłacie dane osobowe do modelu działającego u zewnętrznego dostawcy, ten dostawca przetwarza je na Wasze zlecenie. To wymaga umowy powierzenia o konkretnej treści — i to Wy odpowiadacie za to, że ją macie, nawet jeśli korzystacie z usługi za sześćdziesiąt złotych miesięcznie opłacanej kartą.

Cztery rzeczy, które sprawdzamy w pierwszej kolejności w każdym audycie, bo rozstrzygają o ryzyku szybciej niż cała reszta dokumentacji:

• Czy plan, z którego korzystacie, wyłącza trenowanie modeli na Waszych danych. Różnica między wersją konsumencką a firmową tego samego narzędzia to zwykle właśnie ten zapis — i tylko w jednej z nich da się zbudować zgodne wdrożenie. Sprawdzajcie konkretny plan i konkretny interfejs, bo warunki potrafią się różnić między aplikacją i API tego samego dostawcy.
• Jaka jest retencja danych po stronie dostawcy i czy da się ją skrócić. Typowe trzydzieści dni „na potrzeby bezpieczeństwa” oznacza, że przez miesiąc kopia Waszych promptów żyje poza Waszą infrastrukturą. Część dostawców pozwala to wyłączyć — zwykle tylko na wyraźny wniosek.
• Gdzie dane są przetwarzane i na jakiej podstawie trafiają poza Europejski Obszar Gospodarczy. Jeśli kraj odbiorcy nie ma decyzji o adekwatności lub dostawca nie jest objęty obowiązującym mechanizmem transferowym, potrzebne są standardowe klauzule umowne i ocena ryzyka transferu. Opcja regionu europejskiego, jeśli dostawca ją oferuje, upraszcza ten wątek najtaniej.
• Lista podprzetwarzających i tryb jej zmiany. Dostawcy modeli opierają się na innych dostawcach chmury, a Wy powinniście wiedzieć, kto jeszcze dotyka tych danych i czy macie prawo sprzeciwu wobec nowego podmiotu w łańcuchu.

Co zrobić, gdy dostawca nie da się przekonać

Czasem wynik tej analizy jest negatywny: narzędzie jest dobre, ale warunki przetwarzania nie dają się pogodzić z zakresem danych, które chcecie przez nie przepuścić. Są wtedy trzy wyjścia i wszystkie są tańsze niż wdrożenie, które trzeba będzie wyłączyć.

Pierwsze: ograniczyć dane, nie narzędzie. Usunięcie identyfikatorów przed wysłaniem promptu — nazwisk, adresów, numerów umów, numerów telefonu — zwykle nie pogarsza jakości odpowiedzi, bo model i tak pracuje na treści problemu, a nie na tożsamości osoby. Pseudonimizacja wykonana przed wyjściem danych z Waszej infrastruktury jest najbardziej opłacalnym środkiem ograniczającym ryzyko w całym projekcie.

Drugie: ograniczyć zakres wdrożenia do procesów bez danych osobowych. Dokumentacja wewnętrzna, procedury, treści marketingowe, dane techniczne — to pełnowartościowe zastosowania, które dają zwrot i nie wymagają żadnej z opisanych wyżej analiz.

Trzecie: przenieść model bliżej siebie. Model uruchomiony we własnej infrastrukturze zdejmuje wątek transferu i powierzenia prawie w całości, za cenę wyższych kosztów utrzymania i niższej jakości względem najlepszych modeli komercyjnych. Kiedy ten rachunek się domyka, policzyliśmy w tekście o lokalnym modelu AI w firmie. Nie jest to rozwiązanie domyślne — jest rozwiązaniem dla konkretnych rodzajów danych.

Prawa osób: najtrudniejszy punkt całego wdrożenia

Tu rozbijają się wdrożenia, które pod każdym innym względem były przygotowane porządnie. Osoba, której dane dotyczą, może zażądać dostępu do swoich danych, ich sprostowania, usunięcia lub ograniczenia przetwarzania. Macie na odpowiedź miesiąc. Pytanie brzmi: czy jesteście w stanie wykonać to w systemie, w którym dane są rozsypane po bazie wektorowej, logach rozmów i historii promptów.

Trzy warstwy wymagają trzech różnych mechanizmów. Dokumenty źródłowe są najprostsze — usuwa się plik. Indeks wektorowy wymaga ponownego przeliczenia po usunięciu źródła; jeśli nie macie procedury reindeksacji, usunięcie pliku nie usuwa jego treści z odpowiedzi asystenta. Logi i historia rozmów to warstwa, o której pamięta najmniej firm, a która często zawiera najwięcej szczegółów.

Jeśli dostrajaliście model na danych osobowych, uczciwa odpowiedź jest niewygodna: usunięcie pojedynczej osoby z wag modelu nie jest operacyjnie wykonalne. Dlatego decyzja o dostrajaniu na danych klientów lub pracowników powinna być podejmowana świadomie, z zapisanym uzasadnieniem i z planem na ten wniosek — a nie jako techniczny detal po stronie wykonawcy.

Osobna kategoria to decyzje podejmowane automatycznie. Jeśli system samodzielnie rozstrzyga o czymś, co ma dla człowieka istotny skutek — odrzuca kandydaturę, odmawia finansowania, blokuje konto — wchodzą wymogi dotyczące decyzji zautomatyzowanych: informacja, prawo do interwencji człowieka i prawo do zakwestionowania decyzji. Najczęstszy błąd polega na uznaniu, że skoro człowiek formalnie zatwierdza wynik, to decyzja nie jest automatyczna. Jeżeli zatwierdzający nie ma realnej możliwości zmiany rekomendacji ani informacji, na czym ją oparto, jest to decyzja automatyczna z dekoracją. Szczegóły w rekrutacji opisaliśmy w tekście o AI w rekrutacji po AI Act.

Logi są jednocześnie dowodem i ryzykiem

Dwa reżimy ciągną tu w przeciwne strony i trzeba to rozstrzygnąć świadomie, bo samo się nie ułoży. AI Act dla zastosowań wysokiego ryzyka oczekuje przechowywania zapisów działania systemu przez co najmniej sześć miesięcy. RODO każe przechowywać dane nie dłużej, niż jest to niezbędne do celu.

Sprzeczność jest pozorna i rozwiązuje się przez rozdzielenie tego, co zapisujecie. Do wykazania nadzoru nad systemem wystarczają zwykle metadane: kiedy, jaki proces, jaka wersja modelu, jaki wynik, czy nastąpiła eskalacja do człowieka. Pełna treść rozmowy z danymi osobowymi jest potrzebna krótko i tylko do oceny jakości — tygodnie, nie lata.

Praktyczny układ, który się broni: metadane z długą retencją, treści z krótką i automatycznym usuwaniem, próbka interakcji do przeglądu jakości pseudonimizowana przy zapisie. Taki podział zaspokaja oba reżimy i jednocześnie nie psuje monitoringu, o którym pisaliśmy w tekście o utrzymaniu AI po wdrożeniu.

Każda z tych retencji musi być zapisana w rejestrze czynności przetwarzania. Jeżeli wdrożenie AI nie pojawiło się w Waszym rejestrze, formalnie nie istnieje — a to pierwsza rzecz, o którą pyta kontrola, bo jest najłatwiejsza do sprawdzenia.

Siedem dokumentów, które domykają temat

Lista jest krótsza, niż sugeruje większość ofert doradczych. Dla typowego wdrożenia w firmie na kilkadziesiąt osób to praca na kilka dni, nie na kwartał.

1. Wpis w rejestrze czynności przetwarzania dla każdego procesu z AI — z celem, kategoriami danych, podstawą prawną, odbiorcami i okresem retencji.
2. Analiza ryzyka, a dla procesów z wykazu organu — pełna ocena skutków dla ochrony danych, z opisem środków ograniczających ryzyko.
3. Zapisany test uzasadnionego interesu, jeśli to on jest podstawą. Trzy kroki, trzy akapity, data i osoba, która go wykonała.
4. Umowa powierzenia z każdym dostawcą, który przetwarza dane — wraz z informacją o podprzetwarzających i podstawą transferu poza EOG.
5. Zaktualizowana informacja dla klientów i pracowników o tym, że w procesie wykorzystywane są narzędzia AI, z zakresem i celem. To zarazem wykonanie obowiązku przejrzystości z AI Act.
6. Wewnętrzna zasada korzystania z AI: jakie dane wolno wkleić, do których narzędzi, co jest zakazane, do kogo zgłaszać wątpliwości. Jedna strona, którą ludzie przeczytają, działa lepiej niż regulamin na dwadzieścia.
7. Procedura realizacji wniosków osób — konkretnie: kto, w jakich systemach i w jakiej kolejności usuwa dane, włącznie z reindeksacją bazy wiedzy i czyszczeniem logów.

Pięć błędów, które widzimy najczęściej

• „To tylko pilotaż.” Pilotaż na prawdziwych danych klientów jest przetwarzaniem danych osobowych w pełnym zakresie. Status projektu wewnątrz firmy nie jest kategorią prawną.
• Zgoda jako podstawa wszystkiego. Najszybsza droga do wdrożenia, które trzeba będzie przebudować po pierwszym odwołaniu zgody albo po pierwszym pytaniu o dobrowolność u pracowników.
• Indeksowanie „całego dysku”, żeby asystent miał pełny kontekst. Zakres uprawnień systemu musi odpowiadać zakresowi uprawnień osoby, która go używa — inaczej zbudowaliście kanał obejścia kontroli dostępu.
• Narzędzie do notatek ze spotkań włączane bez poinformowania uczestników. Osobny, bardzo konkretny problem, który rozłożyliśmy w tekście o notatkach AI ze spotkań — i jedno z najczęstszych źródeł skarg.
• Zgodność dopinana na końcu. Zmiana podstawy prawnej albo zakresu danych po uruchomieniu systemu kosztuje wielokrotnie więcej niż ta sama decyzja podjęta przed wyborem dostawcy.

Od czego zacząć

Pierwszy krok zajmuje dwie godziny i nie wymaga prawnika: wypiszcie na jednej stronie każdy proces, w którym firma dziś używa AI, a obok — jakie dane osobowe tam wchodzą, do jakiego dostawcy trafiają, na jakiej podstawie je przetwarzacie i gdzie zostaje ich kopia. Pola, których nie potraficie wypełnić, są dokładną listą tego, co trzeba uzupełnić — i zwykle okazuje się, że dotyczy to dwóch procesów, nie wszystkich.

Drugi krok to decyzja, która zdejmuje najwięcej ryzyka za najmniejsze pieniądze: dla każdego z tych procesów sprawdźcie, czy dane identyfikujące osoby są tam w ogóle potrzebne. W większości przypadków nie są, a ich usunięcie przed wysłaniem do modelu rozwiązuje połowę problemu, zanim zacznie się rozmowa o dokumentach.

Prowadzimy ten przegląd jako część audytu przed wdrożeniem — inwentaryzacja danych w procesach, ocena podstaw prawnych, weryfikacja warunków dostawców i projekt środków ograniczających ryzyko, razem z architekturą samego rozwiązania. Jeśli macie wdrożenie, które powstało bez tej analizy, albo planujecie start i chcecie ustawić to porządnie od pierwszego dnia, umówcie bezpłatną konsultację albo zobaczcie, jak wygląda nasz konsulting i wdrożenia AI.

Niniejszy tekst ma charakter informacyjny i nie stanowi porady prawnej — ocena konkretnego wdrożenia zależy od zakresu danych i procesu, a przy przetwarzaniu wysokiego ryzyka warto skonsultować ją z inspektorem ochrony danych lub radcą prawnym.