Ryzyko pracy z plikami wrażliwymi w narzędziach AI
Czym różni się wrzucenie pliku do AI od wysłania maila
Dla prawnika, lekarza czy finansisty wysłanie dokumentu mailem do zaufanego odbiorcy jest oswojoną czynnością: znany adresat, zwykle szyfrowane połączenie, jasno określony cel. Gdy ten sam plik trafia do narzędzia AI, przestaje być oczywiste, kto i w jakim zakresie ma do niego dostęp. Z perspektywy bezpieczeństwa różnice są fundamentalne.
Mail trafia do konkretnego podmiotu (np. drugiej kancelarii, szpitala, banku), z którym często istnieje umowa, relacja zawodowa lub choćby możliwość ustalenia odpowiedzialności. Plik wrzucony do narzędzia AI trafia do infrastruktury dostawcy, gdzie może być:
przetwarzany w wielu centrach danych (różne kraje, różne reżimy prawne),
tymczasowo lub długotrwale przechowywany w logach i backupach,
współdzielony z podwykonawcami świadczącymi usługi techniczne,
wykorzystywany do dalszego trenowania modeli (jeśli tak wynika z regulaminu).
Nawet jeśli dane są szyfrowane w transmisji, pozostaje pytanie: jakie operacje wykonuje na nich dostawca i jak długo je przechowuje. W zawodach regulowanych to nie jest drobny szczegół – to punkt wyjścia do oceny zgodności z RODO i z przepisami o tajemnicy zawodowej.
Jak działa model generatywny z perspektywy przepływu danych
Modele generatywne (LLM, systemy analizy dokumentów, asystenci AI) przetwarzają dane w kilku krokach. Uproszczony przepływ wygląda następująco:
Użytkownik wysyła zapytanie (prompt) i/lub plik (np. PDF z dokumentacją medyczną, umową, raportem finansowym).
Serwer dostawcy przyjmuje dane, tworzy z nich wewnętrzną reprezentację, często zapisując logi techniczne.
Model generatywny generuje odpowiedź na podstawie:
udostępnionych danych,
wewnętrznych parametrów modelu,
ewentualnych dodatkowych źródeł (bazy wiedzy, wyszukiwarki).
System zapisuje historię zapytania i odpowiedzi (czasem do wglądu użytkownika, czasem wyłącznie do celów statystycznych lub rozwoju usługi).
W niektórych konfiguracjach dane z zapytań mogą trafić do zestawów treningowych do poprawy jakości modelu.
Kluczowe punkty ryzyka pojawiają się w miejscach, gdzie dane są zapisywane, kopiowane lub analizowane poza ścisłą kontrolą użytkownika. W przypadku zawodów regulowanych każda taka operacja może być kwalifikowana jako nowe przetwarzanie danych osobowych lub tajemnicy zawodowej, co wymaga podstawy prawnej, umowy powierzenia oraz spełnienia szeregu obowiązków informacyjnych.
Przykładowe scenariusze wycieku i nadużyć
Najczęstsze zagrożenia nie wynikają z „hakowania” zaawansowanych systemów, lecz z błędnych decyzji organizacyjnych. Kilka typowych scenariuszy:
Błędna konfiguracja konta – firma korzysta z komercyjnego narzędzia AI, ale nie wyłącza domyślnego trenowania na danych użytkowników; pracownicy wrzucają umowy z danymi klientów, pełne historie chorób, wyciągi bankowe. Dane trafiają do zbiorów wykorzystywanych do „ulepszania modelu”.
Brak polityki bezpieczeństwa – kancelaria pozwala „testować AI”, bez instrukcji. Aplikant zamieszcza w narzędziu pełną treść opinii prawnej, pytając o „prostszą wersję dla klienta”. Treść zawiera wrażliwe dane biznesowe. Kto jest odpowiedzialny? Formalnie – kancelaria.
Korzystanie z darmowych rozwiązań bez VAT/umowy – gabinet lekarski używa bezpłatnego, masowego narzędzia AI do „pomocy w pisaniu opisów badań”. Lekarz wrzuca całe wyniki badań z danymi pacjentów. Regulamin przewiduje szeroką licencję na treści użytkownika i możliwość transferu danych poza EOG.
Udostępnianie ekranu – analityk finansowy wykorzystuje AI wtyczki w przeglądarce. W trakcie wideokonferencji udostępnia ekran z otwartym narzędziem, w którym widać historię poprzednich zapytań z danymi klientów.
W każdym z tych przypadków ryzyko nie wynika z „magii AI”, lecz z niewłaściwego zarządzania procesem: braku procedur, szkoleń, kontroli dostawców.
Specyfika danych w prawie, medycynie i finansach
Prawnik, lekarz i finansista pracują z różnymi kategoriami informacji, ale łączy je jedno – większość to dane wrażliwe lub objęte tajemnicą zawodową.
Prawnicy przetwarzają:
dane identyfikujące klientów (PESEL, NIP, adres, dane kontaktowe),
informacje o postępowaniach karnych, cywilnych, rodzinnych,
dane o majątku, zadłużeniu, relacjach rodzinnych i biznesowych,
korespondencję objętą tajemnicą adwokacką lub radcowską.
Lekarze przetwarzają:
szczególne kategorie danych (stan zdrowia, wyniki badań, historia chorób),
dane o nałogach, życiu seksualnym, możliwych zaburzeniach psychicznych,
informacjami o dochodach, kredytach, zaległościach, inwestycjach,
danymi o strukturach własnościowych, beneficjentach rzeczywistych,
wrażliwymi planami biznesowymi i danymi transakcyjnymi.
W każdym z tych obszarów przypadkowe ujawnienie danych może oznaczać nie tylko naruszenie RODO, ale także złamanie tajemnicy zawodowej oraz naruszenie kontraktów z klientami i pacjentami.
Kluczowe pojęcia: dane wrażliwe, tajemnica i odpowiedzialność
Dane osobowe i szczególne kategorie danych
RODO definiuje dane osobowe jako wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Nie chodzi jedynie o imię i nazwisko – wystarczy kombinacja kilku elementów, która pozwala przypisać informację do konkretnej osoby.
Szczególne kategorie danych obejmują m.in.:
dane o zdrowiu (diagnostyka, leczenie, orzeczenia),
poglądy polityczne i przekonania religijne lub światopoglądowe,
pochodzenie rasowe lub etniczne,
dane biometryczne służące identyfikacji,
dane dotyczące życia seksualnego lub orientacji seksualnej,
dane o członkostwie w związkach zawodowych.
W praktyce zawodów regulowanych większość dokumentów przesyłanych do narzędzi AI zawiera przynajmniej dane osobowe, a bardzo często także dane szczególnej kategorii – zwłaszcza w ochronie zdrowia i w sprawach karnych czy rodzinnych.
Tajemnica zawodowa: prawnicza, lekarska, bankowa
Tajemnica zawodowa to dodatkowy, odrębny od RODO reżim ochrony informacji. Przykładowo:
Tajemnica adwokacka/radcowska obejmuje wszystko, o czym prawnik dowiaduje się w związku z wykonywaniem zawodu: treść dokumentów, korespondencję, notatki z rozmów, strategie procesowe. Obowiązek zachowania tajemnicy jest szeroki i trwa także po zakończeniu współpracy.
Tajemnica lekarska dotyczy wszelkich informacji o pacjencie uzyskanych przy wykonywaniu zawodu, a więc nie tylko dokumentacji medycznej, ale też ustnych relacji, uwag w systemie czy zdjęć diagnostycznych.
Tajemnica bankowa i ubezpieczeniowa obejmuje dane o rachunkach, transakcjach, produktach finansowych, zgromadzonych środkach, jak również wiele informacji pozyskiwanych przy ocenie ryzyka kredytowego lub polisowego.
Naruszenie tajemnicy zawodowej w związku z użyciem narzędzi AI jest traktowane tak samo poważnie, jak tradycyjny wyciek – różni się tylko techniczna ścieżka zdarzeń. Sam fakt, że dane „wyszły” do zewnętrznego dostawcy, który nie jest objęty odpowiednimi umowami, może być uznany za naruszenie.
Administrator danych, procesor i dostawca AI
Żeby uporządkować odpowiedzialność, przydatne jest precyzyjne rozróżnienie ról:
Administrator danych – podmiot, który decyduje o celach i sposobach przetwarzania danych. W praktyce: kancelaria, szpital, przychodnia, bank, dom maklerski, firma doradcza.
Procesor (podmiot przetwarzający) – podmiot, który przetwarza dane w imieniu administratora, na podstawie umowy powierzenia. Może nim być np. dostawca oprogramowania, chmury, narzędzia AI, o ile umowa jasno reguluje role i zakres przetwarzania.
Dostawca narzędzia AI – może być procesorem, ale bywa też odrębnym administratorem, gdy wykorzystuje dane do własnych celów (np. trenowanie modeli, analizy statystyczne niezależne od zleceń klienta).
Co wiemy? Administrator odpowiada wobec pacjenta/klienta za całość procesu, także wtedy, gdy winne jest narzędzie zewnętrzne. Spoczywa na nim obowiązek wyboru dostawcy, zawarcia umowy powierzenia, weryfikacji środków bezpieczeństwa.
Czego jeszcze nie wiemy w pełni? Sądowa praktyka dotycząca konkretnych naruszeń z użyciem generatywnej AI dopiero się kształtuje. Nie ma jeszcze bogatego orzecznictwa, które rozstrzygałoby wszystkie graniczne przypadki, np. odpowiedzialność dyscyplinarną prawnika, który wykorzystał „bezpieczny” system, ale błędnie skonfigurował jego ustawienia prywatności.
Odpowiedzialność dyscyplinarna, administracyjna i cywilna
Naruszenie zasad pracy z danymi wrażliwymi w AI może przełożyć się na kilka równoległych torów odpowiedzialności:
Dyscyplinarna – np. wobec adwokata, radcy, lekarza, biegłego rewidenta, doradcy podatkowego. Ciąży na nich obowiązek zachowania tajemnicy i należytej staranności, także przy wyborze narzędzi IT.
Administracyjna – decyzje i kary organu ochrony danych osobowych (np. za brak podstawy prawnej do transferu danych do dostawcy AI, brak umowy powierzenia, brak analizy ryzyka).
Cywilna – roszczenia odszkodowawcze pacjenta lub klienta za szkodę majątkową lub niemajątkową wynikającą z ujawnienia jego danych (np. pogorszenie sytuacji procesowej, ujawnienie stanu zdrowia, szkoda reputacyjna).
W praktyce te tory mogą się kumulować: kancelaria może otrzymać karę administracyjną, prawnik – ponieść odpowiedzialność dyscyplinarną, a klient – dochodzić odszkodowania cywilnego. Nie są to scenariusze teoretyczne – naruszenia w tradycyjnych systemach IT już do nich prowadziły, a narzędzia AI są oceniane w podobny sposób.
Jak świadomie czytać regulaminy i polityki prywatności narzędzi AI
Najważniejsze zapisy dotyczące danych użytkownika
Regulaminy narzędzi AI często liczą kilkanaście stron i są pisane językiem prawniczo-technicznym. W zawodach regulowanych nie ma jednak alternatywy: to podstawowe źródło informacji o tym, co stanie się z danymi klientów i pacjentów.
Kluczowe sekcje, które wymagają dokładnej lektury:
Przetwarzanie i przechowywanie danych – czy dostawca wyjaśnia, jak długo przechowuje dane z zapytań, gdzie są przechowywane (lokalizacja serwerów), czy dane są szyfrowane w spoczynku i w transmisji.
Użycie danych do trenowania modeli – czy domyślnie dane użytkownika są wykorzystywane do poprawy algorytmów, jak można się z tego wycofać, czy można włączyć całkowity zakaz użycia danych do trenowania.
Udostępnianie podmiotom trzecim – jacy podwykonawcy mają dostęp do danych (np. usługodawcy chmury, firmy analityczne), w jakim zakresie i na jakiej podstawie prawnej.
Prawa do treści użytkownika – czy użytkownik zachowuje pełne prawa do przesyłanych plików i treści, czy dostawca uzyskuje szeroką licencję (np. do dowolnego wykorzystania, publikacji, tworzenia utworów zależnych).
Jeżeli narzędzie jest wykorzystywane w kancelarii, gabinecie lub dziale finansów, treść regulaminu powinna być co najmniej skonsultowana z osobą odpowiedzialną za ochronę danych (IOD, compliance, prawnik wewnętrzny).
Różnice między wersją konsumencką a enterprise
Wiele narzędzi AI oferuje dwie klasyczne ścieżki dostępu: wariant „dla każdego” (często darmowy lub tani) oraz wariant biznesowy/enterprise. Z punktu widzenia bezpieczeństwa różnice bywają zasadnicze.
Typowe cechy rozróżniające:
W wersjach konsumenckich:
dane użytkownika mogą być używane do trenowania modeli,
brzmienie licencji jest szerokie i pozwala na wtórne wykorzystanie treści,
brakuje formalnej umowy powierzenia danych osobowych,
często brak jest gwarantowanej lokalizacji danych (np. mogą być przetwarzane globalnie).
W wersjach enterprise:
można wyłączyć trenowanie na danych klienta lub domyślnie jest ono wyłączone,
Parametry bezpieczeństwa, których szukać w wersjach biznesowych
Nie każda oferta oznaczona jako „enterprise” faktycznie zapewnia poziom bezpieczeństwa akceptowalny dla prawnika, lekarza czy CFO. Przy analizie oferty technicznej i prawnej pojawia się kilka powtarzających się elementów.
Wyłączone trenowanie na danych klienta – zapis wprost w regulaminie lub umowie, że dostawca nie wykorzystuje treści zapytań, plików i metadanych do trenowania lub udoskonalania modeli ogólnych.
Dedykowana instancja lub logiczna separacja danych – zapewnienie, że dane organizacji są izolowane od innych klientów (oddzielne bazy, klucze szyfrujące, tenant w chmurze).
Możliwość zawarcia umowy powierzenia danych – zgodnej z RODO, z jasnym opisem kategorii danych, celu, zakresu, podwykonawców i środków technicznych.
Ścieżka audytu i logi – dostęp do logów administracyjnych, możliwość integracji z systemami SIEM, raporty bezpieczeństwa.
Wsparcie wdrożeniowe – udział działu bezpieczeństwa dostawcy, udostępnianie DPIA/analiz ryzyka, gotowe wzory klauzul do rejestru czynności przetwarzania.
Co wiemy? Oferta „dla biznesu” jest często negocjowalna – zapisy umowne i techniczne standardy da się dopasować do wymogów zawodów regulowanych. Czego nie wiemy bez weryfikacji? Jak dany dostawca faktycznie wdrożył deklarowane środki bezpieczeństwa – bez audytu lub przynajmniej szczegółowego Q&A nie ma tu automatyzmu.
Chmura publiczna to najczęstszy model udostępniania narzędzi AI – system działa w infrastrukturze dostawcy, współdzielonej z innymi klientami. Dla użytkownika oznacza to niską barierę wejścia i szybkie testy, ale także ograniczoną kontrolę nad tym, co dzieje się „pod spodem”.
Najczęstsze korzyści:
szybkie wdrożenie bez inwestycji w sprzęt i zespół IT,
dostęp do najnowszych modeli i aktualizacji bezpieczeństwa,
skalowalność – łatwe zwiększanie mocy obliczeniowej przy większej liczbie spraw lub pacjentów.
Główne ograniczenia dla zawodów regulowanych:
transfer danych poza EOG (np. do USA) i wynikające z tego wymogi prawne,
konieczność zaufania deklaracjom bezpieczeństwa, bez pełnej przejrzystości technicznej,
trudniejsza integracja z wewnętrznymi procedurami nadawania ról i uprawnień.
W praktyce część kancelarii i szpitali wybiera model hybrydowy: w chmurze publicznej działają narzędzia do pracy na danych już zanonimizowanych, natomiast dokumenty w pełni identyfikujące osoby są przetwarzane w bardziej kontrolowanym środowisku.
Chmura prywatna i rozwiązania sektorowe
Chmura prywatna to infrastruktura, która działa w data center dostawcy lub klienta, ale jest przeznaczona dla jednego podmiotu lub ograniczonej grupy podmiotów (np. konsorcjum szpitali, banków). W kontekście AI taki model zaczyna się pojawiać w sektorach wymagających wyższego poziomu kontroli.
Typowe cechy takich wdrożeń:
wyraźnie określona lokalizacja danych (np. wyłącznie centra danych w Polsce lub UE),
ściślejsza kontrola dostępu administratorów dostawcy,
możliwość zastosowania niestandardowych środków, np. własne klucze szyfrujące (customer managed keys).
Dla prawnika czy lekarza kluczowa jest informacja, czy chmura prywatna jest faktycznie odseparowana od środowisk ogólnych dostawcy, czy tylko marketingowo nazywana „private”. Różnica jest istotna, gdy pojawia się pytanie o potencjalny wyciek lub incydent u innego klienta.
On‑premise: maksymalna kontrola, realne koszty
Model on‑premise oznacza, że system AI działa w infrastrukturze posiadanej lub bezpośrednio kontrolowanej przez organizację (własne serwery w serwerowni lub wydzielone zasoby w ośrodku przetwarzania danych). To rozwiązanie najbliższe tradycyjnej wizji „wszystko trzymamy u siebie”.
Korzyści są intuicyjne:
pełna kontrola nad tym, gdzie znajdują się dane wrażliwe,
łatwiejsze powiązanie z istniejącymi procedurami bezpieczeństwa (backupy, segmentacja sieci, kontrola fizyczna),
możliwość ograniczenia lub wyłączenia komunikacji z zewnętrznymi serwerami.
Cena jest jednak wymierna: inwestycje w sprzęt (GPU), zespół specjalistów, utrzymanie i aktualizacje modeli. W wielu mniejszych podmiotach medycznych czy kancelariach to po prostu poza zasięgiem, chyba że wdrożenie jest realizowane grupowo (np. izba lekarska, samorząd adwokacki jako organizator usługi).
Jak dobrać model do rodzaju danych i skali organizacji
Dobór modelu wdrożenia nie powinien być wyłącznie decyzją działu IT. W kancelarii czy szpitalu naturalnym punktem wyjścia jest typ danych, z jakimi system ma pracować, oraz częstotliwość użycia.
Eksperymentalne użycie, mała skala – raczej narzędzia chmurowe, ale z zaszytymi mechanizmami anonimizacji i twardym zakazem wprowadzania pełnych danych identyfikujących.
Stałe użycie przy wsparciu diagnostyki lub analizy spraw – rozwiązania enterprise w chmurze publicznej lub prywatnej, z umową powierzenia i jasno opisanymi granicami danych wrażliwych.
Systemowe wykorzystanie na dużą skalę (np. sieć szpitali, duża grupa kapitałowa) – częściej hybryda lub on‑premise, gdzie najbardziej wrażliwe dane (np. surowe dane medyczne, pełne akta spraw karnych) nie opuszczają infrastruktury kontrolowanej bezpośrednio.
Kluczowe dobre praktyki przed wysłaniem jakiegokolwiek pliku do AI
Wstępna kwalifikacja danych: co w ogóle może trafić do AI
Zanim pojawi się pytanie o szyfrowanie czy klauzule umowne, pada zazwyczaj inne: czy w tym konkretnym przypadku wolno przesłać plik do narzędzia AI, nawet gdy formalnie jest „bezpieczne”? Odpowiedź powinna wynikać z wewnętrznej polityki organizacji.
Praktycznym narzędziem jest prosty podział:
Dane zakazane – np. pełna dokumentacja medyczna, akta sprawy karnej, pełne zestawienia transakcji klienta z numerami rachunków i PESEL. Tego typu treści nie są przekazywane do zewnętrznego AI w ogóle, chyba że w ramach ściśle kontrolowanego projektu i po silnej anonimizacji.
Dane warunkowe – np. fragmenty umów, wypisy historii choroby, z których usunięto identyfikatory bezpośrednie. Mogą być użyte w AI, jeśli spełnione są określone warunki (określony dostawca, wersja enterprise, wyłączone trenowanie).
Dane neutralne – materiały szkoleniowe, ogólne procedury, szablony bez danych konkretnych osób. Zwykle mogą być przetwarzane szerzej, choć również warto je klasyfikować.
Takie kategoryzacje najlepiej działają, gdy są opisane w jednym dokumencie roboczym i omówione na krótkim szkoleniu – inaczej każda osoba w zespole zaczyna interpretować je na własny sposób.
Minimalizacja danych: usuń wszystko, co nie jest niezbędne
Jeżeli już zapada decyzja, że dany dokument może być przetwarzany przez AI, kolejny krok to minimalizacja. Chodzi o konkretne pytanie: jakie informacje są niezbędne, żeby narzędzie wykonało swoją pracę?
W praktyce oznacza to m.in.:
usuwanie danych kontaktowych (adres, e‑mail, telefon), jeśli nie są potrzebne do analizy treści,
zastępowanie imion i nazwisk neutralnymi oznaczeniami (np. „Osoba A”, „Pacjent 1”),
wycinanie całych załączników, które nie są istotne dla danego pytania (np. skany dokumentów tożsamości, potwierdzenia przelewów z widocznymi numerami kont).
Prosty przykład z praktyki prawniczej: zamiast przesyłać pełną umowę z danymi wszystkich stron i załącznikami, można wysłać tylko sporne paragrafy, po uprzednim usunięciu nazw własnych i kwot, jeżeli nie wpływają na sens analizy.
Weryfikacja narzędzia i środowiska pracy
Przed pierwszym użyciem narzędzia AI wobec danych klientów i pacjentów warto przejść krótką listę kontrolną:
czy narzędzie jest dopuszczone do użytku w organizacji (lista zatwierdzonych rozwiązań),
czy został zawarty stosowny kontrakt/umowa powierzenia,
czy konto użytkownika ma właściwe uprawnienia i czy dostęp jest zabezpieczony (MFA, silne hasło),
czy ustawienia prywatności i logowania są skonfigurowane zgodnie z polityką bezpieczeństwa.
Praca z narzędziem AI z prywatnego laptopa, na publicznej sieci Wi‑Fi, bez szyfrowania dysku i dodatkowego uwierzytelniania, wprowadza dodatkowe ryzyka, niezależne od samego dostawcy modelu. W razie incydentu krytyczne będzie nie tylko „co zrobił dostawca”, ale także „jakie środki stosował profesjonalista po swojej stronie”.
Dokumentowanie decyzji i audytowalność
W wielu organizacjach pojawia się pytanie: jak udowodnić po czasie, że wykorzystanie AI było zgodne z procedurami? Bez prostego systemu dokumentowania decyzji i konfiguracji narzędzi może to być trudne.
Stosuje się m.in.:
krótkie opisy celu użycia AI przy danym zadaniu (np. w notatkach w systemie sprawy czy historii pacjenta),
rejestr narzędzi i modeli dopuszczonych do użytku wraz z datą akceptacji i parametrami prywatności,
okresowe przeglądy – czy dane, które realnie są wysyłane, odpowiadają założeniom z polityki.
To element mniej spektakularny niż szyfrowanie czy audyty SOC 2, ale z punktu widzenia odpowiedzialności dyscyplinarnej często decydujący: pokazuje, że organizacja nie działała na oślep.
Anonimizacja i pseudonimizacja dokumentów krok po kroku
Anonimizacja a pseudonimizacja: różnica praktyczna
W języku prawnym i technicznym pojęcia te nie są zamienne. Anonimizacja to takie przekształcenie danych, które uniemożliwia identyfikację osoby w rozsądny sposób. Pseudonimizacja – jedynie utrudnia identyfikację, ale przy użyciu dodatkowych informacji (np. klucza, tabeli powiązań) pozwala wrócić do tożsamości.
Dla prawnika, lekarza czy doradcy finansowego różnica ma wymiar praktyczny:
dane zanonimizowane przestają być danymi osobowymi (przy spełnieniu rygorystycznych warunków),
dane pseudonimizowane nadal są danymi osobowymi i podlegają pełnemu reżimowi ochrony.
W kontekście pracy z narzędziami AI większość operacji to de facto pseudonimizacja: dane są „przykryte” identyfikatorami, ale organizacja zachowuje możliwość przywrócenia pełnej treści w swoich systemach.
Etap 1: identyfikacja elementów umożliwiających rozpoznanie osoby
Przy obróbce dokumentów pod kątem AI trzeba spojrzeć na nie szerzej niż tylko przez pryzmat imienia i nazwiska. Do identyfikacji mogą prowadzić:
identyfikatory bezpośrednie – PESEL, numer dowodu osobistego, NIP, numer rachunku bankowego, adres zamieszkania, e‑mail imienny, numer telefonu,
identyfikatory pośrednie – stanowisko w niszowej firmie, opis rzadkiej choroby w małej miejscowości, połączenie daty zdarzenia z miejscem i funkcją pełnioną przez osobę.
W praktyce tworzy się listę pól i fragmentów tekstu, które wymagają modyfikacji. Przy masowym przetwarzaniu pomocne są szablony lub półautomatyczne narzędzia anonimizujące, ale ostateczna kontrola i tak powinna być po stronie człowieka.
Etap 2: wybór metody przekształcenia danych
Są co najmniej trzy główne sposoby, które stosują kancelarie i podmioty medyczne:
Maskowanie – częściowe ukrycie danych (np. „Jan K.” zamiast pełnego nazwiska, ostatnie cztery cyfry numeru rachunku). Wciąż może to być dane osobowe, ale ryzyko identyfikacji spada.
Agregacja – zamiast konkretnych wartości podaje się zakresy (wiek zamiast daty urodzenia, „duże miasto w Polsce” zamiast konkretnej miejscowości), co utrudnia identyfikację pojedynczej osoby.
Tokenizacja/pseudonimizacja – zastępowanie danych identyfikujących losowymi oznaczeniami („Pacjent_123”, „Klient_X”), które mają znaczenie tylko w wewnętrznej bazie.
Wybór metody zależy od tego, czy dane mają pozostać użyteczne analitycznie. W medycynie wiek pacjenta może mieć kluczowe znaczenie, ale dokładny adres już nie. W finansach konkretny numer rachunku jest rzadko potrzebny do analizy struktury transakcji.
Etap 3: anonimizacja treści nieustrukturyzowanej
Etap 3: anonimizacja treści nieustrukturyzowanej – praktyczne techniki
Najwięcej problemów sprawiają dokumenty opisowe: historie choroby, uzasadnienia wyroków, notatki z analizy ryzyka. Dane identyfikujące pojawiają się tam w środku zdań, czasem w kilku wariantach (nazwisko w mianowniku, dopełniaczu, skrócone imię).
W praktyce stosuje się sekwencję kroków:
wstępne wyszukiwanie wzorców – PESEL, numery telefonów, adresy e‑mail, numery rachunków bankowych wyszukiwane za pomocą wyrażeń regularnych,
lista nazw własnych – ręczne wyłapanie imion, nazwisk, nazw firm, placówek medycznych; często powstaje mały „słownik” dla danego pliku lub sprawy,
systematyczne zastępowanie – każda nazwa otrzymuje stały odpowiednik („Pacjent 1”, „Szpital X”), żeby tekst pozostał spójny,
ostatni przegląd z perspektywy „znajomego z miasta” – pytanie, czy ktoś z tej samej miejscowości, znający kontekst lokalny, byłby w stanie odgadnąć, o kogo chodzi.
Przykład z gabinetu: opis rzadkiej choroby u jedynego specjalisty w małej miejscowości, połączony z datą zabiegu, może wskazywać konkretną osobę, nawet jeśli imię i nazwisko zostały usunięte. W takich sytuacjach bezpieczniej jest zmienić lub uogólnić miejsce i datę.
Etap 4: zarządzanie kluczami i tabelami powiązań
Pseudonimizacja wymaga osobnego zarządzania „słownikiem” powiązań między prawdziwymi danymi a ich odpowiednikami w dokumentach przygotowanych dla AI. To newralgiczny element całego procesu.
W dojrzałych organizacjach wygląda to zwykle tak:
oddzielny system lub plik referencyjny – przechowywany w innym miejscu niż dane pseudonimizowane, z odrębnymi uprawnieniami dostępu,
jasno opisane role – kto może tworzyć i edytować powiązania, a kto tylko je odczytywać; często dostęp ograniczony do kilku osób zaufania publicznego (np. ordynator, partner kancelarii, dyrektor compliance),
rejestrowanie zmian – każda modyfikacja w tabeli powiązań zostawia ślad: kto, kiedy, w jakim celu.
Bez takich mechanizmów pseudonimizacja staje się iluzoryczna – osoba z dostępem do obu zbiorów (tekstów dla AI i słownika) może bez większego wysiłku odtworzyć pełną historię pacjenta czy klienta.
Etap 5: kontrola skuteczności anonimizacji
Kluczowe pytanie brzmi: czy po serii przekształceń dokument nadal spełnia swój cel (diagnostyczny, analityczny, szkoleniowy), a jednocześnie nie pozwala zidentyfikować osoby? Odpowiedź rzadko jest zero-jedynkowa.
W praktyce stosuje się kilka prostych testów:
test „osoby trzeciej” – inny członek zespołu, który nie prowadzi sprawy ani nie zna pacjenta, ocenia, czy na podstawie tekstu jest w stanie wskazać konkretną osobę,
test lokalny – zastanowienie się, czy w danym środowisku (np. jedna dzielnica, mała miejscowość) kombinacja opisanych cech nie prowadzi wprost do jednej osoby,
test przydatności – czy po usunięciu danych wrażliwych dokument nadal odpowiada na pytanie, z którym ma pracować AI (np. analiza konstrukcji umowy, opis przebiegu leczenia).
Jeżeli odpowiedzi są niejednoznaczne, bezpieczniej jest przyjąć, że mamy do czynienia z danymi osobowymi i zastosować pełne środki ochrony oraz ograniczyć zakres przesyłanych informacji.
Typowe błędy przy anonimizacji w praktyce zawodowej
W relacjach z praktyków powtarza się kilka scenariuszy, które zwiększają ryzyko, mimo formalnego „zamazania” danych.
Usunięte nazwisko, pozostawione inicjały i stanowisko – w małej spółce lub wąskiej specjalizacji taka kombinacja bywa wystarczająca, by zidentyfikować konkretną osobę.
Zbyt wiele szczegółów czasowo-miejscowych – precyzyjne daty, numery sal operacyjnych, nazwy ulic, rzadkie procedury medyczne, opisy lokalnych wydarzeń.
Mieszanie poziomów anonimizacji – w jednym akapicie „Pacjent 1”, w innym pełne imię, w trzecim tylko nazwisko. AI poradzi sobie z takim tekstem, ale człowiek również, łącząc tropy w całość.
Brak spójnego słownika – kilka różnych określeń tej samej osoby („Klient A”, „Kupujący”, „Pan X”) sprawia, że ktoś próbujący zachować anonimizację po pewnym czasie sam traci orientację, z kim właściwie wiąże się dany fragment opisu.
W wielu sytuacjach drobna zmiana opisu („średnie miasto w centralnej Polsce” zamiast konkretnej miejscowości, przedział czasowy zamiast daty) znacząco obniża ryzyko identyfikacji bez utraty sensu analizy.
Konfiguracja narzędzi AI: ustawienia prywatności, logów i przechowywania danych
Kluczowe pytania przed włączeniem nowego narzędzia
Zanim dane wrażliwe trafią do jakiegokolwiek modelu, przydaje się krótka lista kontrolna. Co wiemy o dostawcy? Czego nie wiemy o tym, co dzieje się z danymi po stronie systemu?
Najczęściej sprawdzane elementy to:
czy dostawca używa danych do trenowania modeli – i czy istnieje techniczna możliwość całkowitego wyłączenia takiego wykorzystania dla konta organizacji,
jak długo przechowywane są logi i treści zapytań – oraz czy okres ten można skrócić lub wymusić wcześniejsze usunięcie,
gdzie fizycznie znajdują się serwery – co ma znaczenie dla tajemnicy zawodowej, transferów poza EOG i obowiązków informacyjnych,
jakie mechanizmy audytu są dostępne – podgląd historii zapytań, eksport logów, szczegółowe uprawnienia dla administratorów.
Bez odpowiedzi na te pytania trudno uczciwie ocenić, czy narzędzie nadaje się choćby do pracy z danymi pseudonimizowanymi, a tym bardziej z pełną dokumentacją.
Ustawienia prywatności na poziomie organizacji i użytkownika
Wiele komercyjnych narzędzi AI oferuje dwa poziomy konfiguracji: globalny (dla całej organizacji) i indywidualny (dla konta użytkownika). Z punktu widzenia odpowiedzialności zawodowej ważne jest, która warstwa ma priorytet.
W praktyce można wyróżnić kilka modeli:
Polityka centralnie egzekwowana – administrator organizacji narzuca sztywne ustawienia (brak trenowania na danych klientów, minimalny zakres logów, limity przechowywania), których użytkownik nie może zmienić.
Polityka ramowa z możliwością zaostrzenia – organizacja ustawia minimalny standard, ale użytkownik może dodatkowo wyłączyć np. przechowywanie historii czatów dla swoich sesji.
Pełna swoboda użytkownika – najtrudniejsza do udokumentowania i obrony w razie incydentu. W sektorach regulowanych taki model bywa akceptowalny wyłącznie przy pracy na danych całkowicie zanonimizowanych.
Szczególne znaczenie mają funkcje typu „history disabled” lub „incognito mode” w interfejsach czatowych – ograniczają one zapisywanie treści konwersacji, ale nie zawsze wyłączają inne formy przetwarzania (np. krótkotrwałe buforowanie czy analitykę systemową).
Logi i ślady aktywności: co faktycznie jest zapisywane
Logi systemowe bywają niedoceniane. Dla prawnika czy lekarza liczy się tekst rozmowy z AI, tymczasem dla działu bezpieczeństwa ważniejsza bywa metryka i kontekst: kto, kiedy, z jakiego urządzenia i z jakiej lokalizacji wykonał zapytanie.
logi dostępowe – logowania, próby logowania, zmiany haseł, włączenie/wyłączenie MFA,
logi administracyjne – zmiany konfiguracji, nadawanie i odbieranie uprawnień, integracje z innymi systemami.
Z punktu widzenia ochrony danych kluczowe są dwa obszary: czy w treści logów nie pojawiają się pełne dane klientów/pacjentów (np. w opisach błędów) oraz jak długo te logi są przechowywane i kto ma do nich dostęp. W niektórych rozwiązaniach konieczne jest wyłączenie szczegółowych logów debugujących przed przejściem na dane rzeczywiste.
Czas przechowywania danych i mechanizmy ich usuwania
Przepisy i dobre praktyki wymagają, żeby dane nie były przechowywane dłużej, niż to konieczne do celu, w jakim zostały zebrane. W narzędziach AI ten czas często jest z góry określony w regulaminie – od kilku dni do kilkunastu miesięcy.
Przy wdrożeniach w sektorach regulowanych analizuje się zazwyczaj:
czas przechowywania historii zapytań – osobno dla interfejsu przeglądarkowego, osobno dla API, bo mogą się różnić,
czas przechowywania logów systemowych – które nawet bez treści zapytań mogą zawierać wrażliwe metadane (np. identyfikator użytkownika połączony z opisem operacji),
dostępność funkcji „hard delete” – trwałego usuwania danych, także z kopii zapasowych, lub przynajmniej ich nieodwracalnego zanonimizowania.
Pytanie kontrolne brzmi: co dzieje się z danymi po rozwiązaniu umowy z dostawcą lub zamknięciu konta? W wielu umowach jest to opisane ogólnie; w praktyce dobrze jest uzyskać precyzyjne wyjaśnienie oraz – jeśli to możliwe – potwierdzenie wykonania usunięcia w formie raportu technicznego.
Bezpieczeństwo dostępu: MFA, segmentacja i urządzenia końcowe
Nawet najlepiej skonfigurowany model traci sens, jeśli dostęp do niego jest słabo chroniony. Incydenty często zaczynają się od przejęcia konta użytkownika, a nie od spektakularnego włamania do centrum danych.
W praktyce sprawdza się kilka podstawowych zasad:
wymuszone uwierzytelnianie wieloskładnikowe (MFA) – szczególnie dla kont z dostępem do ustawień organizacyjnych i logów,
segmentacja uprawnień – inni użytkownicy do pracy rutynowej, inni do zarządzania integracjami API, jeszcze inni do audytu i raportowania,
polityka urządzeń końcowych – szyfrowane dyski, blokada kopiowania treści na niezaufane urządzenia, ograniczenie dostępu z prywatnych komputerów lub przynajmniej wyższy próg zabezpieczeń dla takich logowań.
Kancelarie i szpitale coraz częściej stosują zasadę: dostęp do narzędzi AI z danymi pacjentów/klientów wyłącznie z urządzeń zarządzanych centralnie (MDM), z możliwością zdalnego wymazania danych w razie utraty sprzętu.
Konfiguracja integracji API i środowisk testowych
Gdy narzędzie AI jest integrowane z wewnętrznymi systemami – np. z systemem informacji szpitalnej, CRM kancelarii czy systemem transakcyjnym – ryzyka rosną. Dane mogą przepływać automatycznie, bez świadomości poszczególnych użytkowników.
Wymaga to kilku dodatkowych decyzji konfiguracyjnych:
oddzielne klucze API dla środowisk produkcyjnych i testowych – żeby dane szkoleniowe i rzeczywiste się nie mieszały,
twardy zakaz używania danych rzeczywistych w środowiskach testowych – nawet po pseudonimizacji; do testów stosuje się sztucznie wygenerowane zestawy danych lub mocno zanonimizowane próbki,
limity i reguły po stronie API – ograniczenia co do typów zapytań, maksymalnej wielkości plików, zakresu dostępnych funkcji modelu.
Warto też upewnić się, czy dostawca umożliwia tzw. „single-tenant API” lub wydzielony projekt, w ramach którego dane organizacji nie są mieszane logicznie z innymi klientami – szczególnie przy integracjach o dużej skali.
Monitorowanie użycia narzędzi AI i reagowanie na incydenty
Sam fakt wdrożenia polityk i konfiguracji nie kończy pracy. Potrzebny jest mechanizm wczesnego wykrywania nieprawidłowego użycia – czy to przez użytkowników, czy w wyniku błędu technicznego.
W praktyce oznacza to m.in.:
regularne przeglądy logów – pod kątem nietypowych godzin logowań, serii zapytań z jednego IP, nagłego wzrostu wolumenu przesyłanych dokumentów,
proste reguły ostrzegawcze – np. alert, gdy w treści zapytań pojawiają się wzorce przypominające PESEL lub numery rachunków bankowych,
procedurę zgłaszania incydentów – czy pracownik wie, do kogo zgłosić omyłkowe przesłanie pełnej dokumentacji i jak szybko można zareagować (np. żądanie usunięcia danych u dostawcy).
Przykład z praktyki finansowej: analityk przez nieuwagę przesyła do modelu pełny eksport transakcji z numerami rachunków. Reakcja w ciągu godzin – zgłoszenie do zespołu bezpieczeństwa, kontakt z dostawcą, udokumentowane żądanie usunięcia danych, wewnętrzny przegląd procedur – może znacząco ograniczyć skutki incydentu i ryzyko odpowiedzialności.
Szkolenie użytkowników a konfiguracja techniczna
Najczęściej zadawane pytania (FAQ)
Czy mogę wrzucać do narzędzi AI dokumenty z danymi klientów lub pacjentów?
Takie działanie jest co do zasady ryzykowne, jeśli nie ma jasnej podstawy prawnej, umowy powierzenia z dostawcą AI i odpowiedniej konfiguracji usługi. W praktyce większość dokumentów prawniczych, medycznych i finansowych zawiera dane osobowe, a często także dane szczególnych kategorii lub informacje objęte tajemnicą zawodową.
Bezpieczne użycie AI wymaga traktowania dostawcy narzędzia jak każdego innego podwykonawcy przetwarzającego dane. Oznacza to: sprawdzenie regulaminu, zawarcie umowy powierzenia, weryfikację lokalizacji serwerów, czasu przechowywania danych i wyłączenie wykorzystywania ich do trenowania modeli, jeśli to możliwe. W razie braku takich gwarancji lepiej nie umieszczać w narzędziu niezanonimizowanych dokumentów.
Czym różni się wysłanie pliku do AI od wysłania go mailem?
Mail trafia do konkretnego, znanego adresata – zwykle podmiotu, z którym łączą nas umowy, relacje zawodowe i jasno określona odpowiedzialność. Plik wrzucony do narzędzia AI trafia do infrastruktury dostawcy, gdzie może być kopiowany między centrami danych, logowany, backupowany i udostępniany podwykonawcom technicznym.
W praktyce oznacza to, że przy mailu łatwiej wskazać, kto i na jakiej podstawie przetwarza dane. Przy narzędziu AI często nie wiemy dokładnie, jakie operacje są wykonywane na pliku, jak długo jest przechowywany i czy nie trafia do zbiorów treningowych. To przekłada się bezpośrednio na ocenę zgodności z RODO i z przepisami o tajemnicy zawodowej.
Czy darmowe narzędzia AI są bezpieczne dla danych wrażliwych?
Darmowe, masowe narzędzia AI są zazwyczaj projektowane do ogólnego użytku, a nie do pracy z danymi objętymi tajemnicą zawodową. Regulaminy takich usług często przewidują szeroką licencję na treści wprowadzane przez użytkownika, możliwość ich wykorzystania do ulepszania modeli oraz transfer danych poza Europejski Obszar Gospodarczy.
Dla prawnika, lekarza czy finansisty oznacza to wysoki poziom ryzyka. Bezpłatne konto, brak faktury i brak formalnej umowy powierzenia zwykle wykluczają legalne przetwarzanie wrażliwych danych klientów czy pacjentów. W takich przypadkach rozsądne minimum to: anonimizacja dokumentów lub używanie wersji komercyjnych z jasno uregulowanym przetwarzaniem danych.
Jakie dane są szczególnie problematyczne przy korzystaniu z AI w prawie, medycynie i finansach?
W prawie są to przede wszystkim: dane identyfikujące klientów, informacje o postępowaniach karnych i rodzinnych, dane o majątku, zadłużeniu, relacjach biznesowych oraz cała korespondencja objęta tajemnicą adwokacką lub radcowską. Ich ujawnienie może naruszać zarówno RODO, jak i obowiązek zachowania tajemnicy zawodowej.
W medycynie krytyczne są dane dotyczące zdrowia, wyników badań, historii chorób, nałogów czy życia seksualnego. W finansach – informacje o dochodach, kredytach, zaległościach, inwestycjach, strukturach własnościowych i planach biznesowych. Każde „wypłynięcie” takich danych do dostawcy AI bez odpowiedniej podstawy prawnej może zostać potraktowane jako incydent bezpieczeństwa.
Jak ograniczyć ryzyko przy pracy z plikami wrażliwymi w narzędziach AI?
Podstawą jest połączenie środków organizacyjnych i technicznych. Od strony organizacyjnej kluczowe są: jasna polityka korzystania z AI w firmie, szkolenia dla personelu, procedury klasyfikacji danych (co wolno, a czego nie wolno wrzucać do AI) oraz wskazanie zatwierdzonych narzędzi i konfiguracji.
Technicznie sprawdza się kilka prostych zasad: używanie kont biznesowych z wyłączonym trenowaniem na danych użytkownika, anonimizacja dokumentów przed wgraniem, ograniczanie zakresu danych do niezbędnego minimum oraz kontrola wtyczek i integracji (np. rozszerzeń przeglądarki), które mogą „widzieć” historię zapytań. Przykład z praktyki: kancelaria pozwala na używanie jednego, skonfigurowanego narzędzia AI tylko do pracy na szablonach i wzorach, a nie na pełnych aktach sprawy.
Kto odpowiada za naruszenie danych przy korzystaniu z narzędzi AI – prawnik/lekarz/finansista czy dostawca AI?
Z punktu widzenia RODO administratorem danych pozostaje podmiot decydujący o celach i sposobach przetwarzania: kancelaria, szpital, gabinet, bank, firma doradcza. To on odpowiada za wybór dostawcy AI, zawarcie umowy powierzenia i ocenę ryzyk. Dostawca AI może być procesorem (podmiotem przetwarzającym) lub odrębnym administratorem – zależnie od modelu usługi i zapisów umowy.
Jeśli dokument z danymi wrażliwymi trafi do narzędzia AI bez podstawy prawnej i bez odpowiednich umów, odpowiedzialność spoczywa przede wszystkim na administratorze, czyli na organizacji, w której działa prawnik, lekarz czy finansista. Dostawca AI ponosi odpowiedzialność w zakresie, w jakim naruszy swoje zobowiązania umowne lub przepisy prawa, ale nie zwalnia to użytkownika z obowiązku prawidłowego zaplanowania przetwarzania danych.
Czy historia zapytań w narzędziu AI też jest ryzykowna pod kątem RODO i tajemnicy?
Tak, ponieważ historia zapytań i załączonych plików to często pełnowartościowy zbiór danych osobowych i danych wrażliwych. Jeśli w promptach pojawiają się imiona, nazwiska, numery identyfikacyjne czy szczegółowe opisy spraw, mamy do czynienia z przetwarzaniem danych, a nie „tylko” z roboczymi notatkami.
Dlatego przy konfiguracji narzędzia AI warto sprawdzić, czy istnieje możliwość wyłączenia zapisywania historii, jakie są okresy przechowywania i kto ma do niej dostęp po stronie dostawcy. W codziennej pracy dobrą praktyką jest także unikanie pełnych danych osobowych w treści zapytań, gdy nie jest to niezbędne do uzyskania merytorycznej odpowiedzi.
Bibliografia
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Dziennik Urzędowy Unii Europejskiej (2016) – Definicje danych osobowych, szczególnych kategorii i zasady przetwarzania
Ustawa z dnia 6 lipca 1982 r. o radcach prawnych. Dziennik Ustaw Rzeczypospolitej Polskiej – Zakres i obowiązek zachowania tajemnicy zawodowej radcy prawnego
Wytyczne 07/2020 dotyczące pojęć administratora i podmiotu przetwarzającego. Europejska Rada Ochrony Danych (2021) – Relacje administrator–procesor, umowy powierzenia, odpowiedzialność
Guidelines on processing personal data in the context of AI. European Data Protection Board – Zalecenia EROD dotyczące stosowania RODO do systemów sztucznej inteligencji
ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection. International Organization for Standardization (2022) – Norma zarządzania bezpieczeństwem informacji, logi, backupy, podwykonawcy
