Firma decyduje się wdrożyć LLM nad wewnętrznymi dokumentami. IT ustawia klucz API, deweloper pisze wrapper, ludzie zaczynają wklejać do modelu oferty, umowy, notatki ze spotkań. Przez pierwszy tydzień wygląda to świetnie. Potem przychodzi DPO i zadaje jedno pytanie: „Gdzie trafią te dane?" I nikt nie potrafi odpowiedzieć.
Ten scenariusz nie jest wyjątkiem — to reguła w wielu firmach w UE. GDPR przy wdrożeniach LLM nie jest problemem akademickim. To konkretna checklista, którą albo macie, albo nie. Ten artykuł rozkłada ją praktycznie: gdzie dokładnie wyciekają dane, co musicie mieć podpisane, kiedy wymagana jest DPIA, i jak decydent może oprzeć się na ustrukturyzowanym frameworku zamiast przeczuciu.
Gdzie wyciekają dane — mapa przepływów
Zanim zajmiecie się kwestiami prawnymi, musicie wiedzieć, co dzieje się technicznie. LLM w produkcji to nie jeden system — to łańcuch komponentów, gdzie każdy jest potencjalnym miejscem wycieku.
Typowy przepływ przy chmurowym LLM wygląda tak:
- Dokument wejściowy (umowa, e-mail, raport) → chunking → embedding → baza wektorowa
- Zapytanie użytkownika → retrieval z bazy wektorowej → kontekst + zapytanie wysyłane do API LLM
- API LLM (np. OpenAI, Anthropic, Google) → przetwarza prompt → zwraca odpowiedź
- Logi i ślady → obserwowalność (Langfuse, LangSmith, własny logging) → potencjalnie kolejne magazyny danych
Każdy z tych kroków może zawierać dane osobowe (Personal Identifiable Information — PII): imię i nazwisko klienta w umowie, e-mail osoby kontaktowej, informacje zdrowotne w raporcie, IBAN w dokumencie płatniczym. Jeśli te dane opuszczą wasz perimeter — a przy chmurowym API opuszczą — jesteście podmiotem przetwarzającym dane osobowe z konkretnymi obowiązkami.
Kolejny przepływ, o którym się zapomina: trening i fine-tuning. Niektórzy dostawcy chmurowi wyraźnie wskazują, że danych przesyłanych przez API nie używają do treningu (OpenAI przy planie enterprise, Anthropic przy API). Jednak domyślne ustawienia różnią się między sobą — a to, co obowiązuje dziś, może zmienić się przy aktualizacji warunków. Zawsze weryfikujcie aktualne Terms of Service i zakotwijcie to umownie.
Cloud API vs. on-prem — decyzja z konsekwencjami dla GDPR
To najważniejszy wybór architektoniczny z punktu widzenia compliance.
Cloud API (OpenAI, Anthropic, Gemini, Azure OpenAI...)
Zalety są oczywiste: najsilniejsze modele, zerowa infrastruktura, szybki start. Problemy z GDPR:
- Dane opuszczają wasz perimeter — jesteście zobowiązani mieć Data Processing Agreement (DPA) z dostawcą jako podmiotem przetwarzającym
- Przy transferze poza EOG (np. dane na serwerach w USA) potrzebujecie mechanizmu transferu — standardowych klauzul umownych (SCC) lub równoważnej podstawy prawnej
- Musicie wiedzieć, gdzie fizycznie znajdują się serwery; odpowiedź „w chmurze" nie wystarczy DPO ani organowi nadzorczemu
Większość dużych dostawców oferuje DPA — ale musicie je aktywnie zawrzeć, a nie tylko kliknąć w checkbox. Azure OpenAI ma europejskie regiony, co upraszcza transfer danych poza EOG. Sprawdzajcie aktualne warunki bezpośrednio u każdego dostawcy.
On-prem / self-hosted LLM
Dane nie opuszczają waszego perimetera. Jeśli model działa na waszych serwerach (lub na serwerach w EOG na podstawie jasnej umowy), ekspozycja na GDPR jest znacznie mniejsza. Ten wybór ma szczególny sens w branżach regulowanych — ochronie zdrowia, prawie, finansach — gdzie przetwarzane są wrażliwe dane osobowe. Dokładniejszą analizę tego tematu znajdziecie w artykule o LLM on-prem dla branż regulowanych.
Kompromisem jest jakość i koszty: self-hosted modele open-weight (Llama, Qwen, Mistral, DeepSeek w wariantach open-weight) osiągają dziś jakość produkcyjną dla większości firmowych przypadków użycia, ale wymagają infrastruktury GPU i zdolności inżynierskich do zarządzania. Do inferencji modelu 7B–14B z rozsądnym opóźnieniem wystarczy z grubsza jeden serwer z GPU o odpowiedniej ilości VRAM; większe modele wymagają więcej zasobów.
DPA — co musi zawierać i dlaczego kliknięcie nie wystarczy
Data Processing Agreement jest wymogiem ustawowym na podstawie artykułu 28 GDPR, gdy przekazujecie dane osobowe stronie zewnętrznej do przetwarzania. Dostawca LLM, któremu przesyłacie dokumenty zawierające dane osobowe, jest podmiotem przetwarzającym. Wy jesteście administratorem. Bez DPA jesteście niezgodni z przepisami.
Co musi zawierać DPA (zgodnie z art. 28 ust. 3 GDPR):
- Przedmiot i czas trwania przetwarzania — konkretnie, nie ogólnikowo
- Charakter i cel przetwarzania — „inference dla wewnętrznego chatbota" jest bardziej konkretny niż „usługi AI"
- Rodzaj danych osobowych i kategorie osób, których dane dotyczą — klienci? pracownicy? pacjenci?
- Obowiązki i prawa administratora — w tym prawo do audytu
- Techniczne i organizacyjne środki bezpieczeństwa (TOMs) — szyfrowanie, kontrola dostępu, reagowanie na incydenty
- Zakaz dalszego podzlecania przetwarzania bez zgody lub ogólne upoważnienie z mechanizmem ustawowym
Uwaga na jeden szczegół, który firmy bagatelizują: DPA musi obejmować również podpodmiotów przetwarzających dostawcy — infrastrukturę chmurową, usługę logowania, narzędzia monitoringowe. Więksi dostawcy publikują listy podpodmiotów przetwarzających; sprawdźcie je.
Podstawa prawna — na jakiej podstawie przetwarzacie dane
GDPR wymaga, aby każde przetwarzanie danych osobowych miało podstawę prawną (art. 6). Przy firmowych wdrożeniach LLM najczęściej spotykamy:
- Uzasadniony interes (art. 6 ust. 1 lit. f) — najczęstsza podstawa dla wewnętrznych narzędzi firmowych; wymaga LIA (Legitimate Interest Assessment), gdzie dokumentujecie, że interes firmy przewyższa prawa osób, których dane dotyczą
- Wykonanie umowy (art. 6 ust. 1 lit. b) — istotne, gdy LLM bezpośrednio służy realizacji umowy z klientem
- Zgoda (art. 6 ust. 1 lit. a) — dla większości narzędzi wewnętrznych niepraktyczna; zgoda musi być dobrowolna, świadoma i odwołalna
Jeśli przetwarzacie szczególne kategorie danych (zdrowotne, genetyczne, biometryczne, polityczne, religijne, związkowe, dotyczące orientacji seksualnej) — art. 9 GDPR — podstawa prawna jest bardziej rygorystyczna, a zgoda jest niemal niezbędna, lub musicie wykazać inną podstawę z enumeratywnego katalogu z art. 9 ust. 2.
Praktycznie: przy LLM nad dokumentacją HR, dokumentacją medyczną lub pismami procesowymi bez prawnika się nie ruszycie. W przeciwnym razie ryzykujecie nie tylko karę, ale i konieczność zatrzymania oraz rozbiórki całego projektu.
PII scrubbing — kiedy i jak
PII scrubbing (oczyszczanie danych osobowych przed wysłaniem do LLM) to środek techniczny, który zmniejsza ekspozycję. Nie zastępuje właściwej podstawy prawnej ani DPA, ale znacznie zawęża powierzchnię ryzyka.
Gdzie ma sens:
- Dokumenty, w których LLM nie potrzebuje znać konkretnego imienia — potrzebuje zrozumieć kontekst, strukturę, treść
- Wpisy w logach — PII nigdy nie powinno znajdować się w logach; to wymóg ustawowy i higiena techniczna zarazem
- Zbiory danych treningowych — jeśli fine-tunujecie model na danych wewnętrznych, PII w danych treningowych może zostać przez model „zapamiętane" (problem memorization) i później ujawnione
Jak to działa technicznie:
- Detektory oparte na regexach — e-maile, numery telefonów, IBAN, numery PESEL, adresy IP; szybkie, deterministyczne, niski odsetek false negative dla ustrukturyzowanych formatów
- Detektory oparte na NER (Named Entity Recognition) — imiona i nazwiska, firmy, adresy; wychwytują teksty nieustrukturyzowane; wymagają modelu, mają wyższy wskaźnik błędów
- Kombinacja — regex dla formatów ustrukturyzowanych + NER dla tekstu swobodnego; produkcyjny standard
Ważne zastrzeżenie: pseudonimizacja to nie anonimizacja w rozumieniu GDPR. Jeśli zastąpicie dane tokenem, ale istnieje klucz do rekonstrukcji, nadal są to dane osobowe. EROD (Europejska Rada Ochrony Danych) wielokrotnie potwierdzała, że LLM rzadko kiedy spełniają standard prawdziwej anonimizacji. Scrubbing zmniejsza ryzyko — nie eliminuje go.
Inspirację przy implementacji pipeline'u oczyszczającego możecie czerpać z artykułu o tym, jak tę warstwę rozwiązują na przykład guardrails dla agentów AI, gdzie walidacja wejścia i detekcja PII stanowi pierwszą linię obrony przed LLM.
Data minimization — nic ponad potrzebę
Data minimization to jedna z kluczowych zasad GDPR (art. 5 ust. 1 lit. c): przetwarzajcie tylko te dane osobowe, które są niezbędne do danego celu.
W przypadku LLM oznacza to w praktyce:
- Do promptu trafiają tylko odpowiednie chunki, nie całe dokumenty — pipeline RAG właściwie skonfigurowany pod kątem precyzyjnego wyszukiwania jest jednocześnie narzędziem compliance
- Polityka retencji dla logów i śladów — jak długo przechowujecie historię konwersacji? 30 dni? 90 dni? Bez zdefiniowanej polityki trwa to „wiecznie"
- Wektory embeddingów — nawet wektorowa reprezentacja dokumentu może być daną osobową, jeśli możliwa jest z niej rekonstrukcja oryginału lub identyfikacja osoby; traktujcie je tak samo jak dane źródłowe
- Logi systemowe inferencji — jeśli logujecie cały prompt wraz z zapytaniem użytkownika, logujecie potencjalnie dane osobowe; wdrożcie selektywne logowanie lub log scrubbing
DPIA — kiedy jest obowiązkowa i co zawiera
Data Protection Impact Assessment (DPIA) jest obowiązkowa przy przetwarzaniu, które „prawdopodobnie spowoduje wysokie ryzyko naruszenia praw lub wolności osób fizycznych" (art. 35 GDPR). Dla wdrożeń LLM oznacza to typowo:
- Systematyczne i rozległe przetwarzanie szczególnych kategorii danych (zdrowotnych, finansowych, HR)
- Zautomatyzowane podejmowanie decyzji o skutkach prawnych lub podobnie istotnych dla osób
- Rozległe monitorowanie przestrzeni publicznie dostępnej
Praktycznie: jeśli wasz LLM pomaga podejmować decyzje dotyczące pracowników, klientów lub pacjentów, DPIA jest wskazana. Jeśli chodzi o wewnętrzny chatbot oparty na dokumentacji technicznej bez szczególnych kategorii danych, DPIA prawdopodobnie nie jest obowiązkowa — ale zalecamy przeprowadzenie przynajmniej wewnętrznej oceny ryzyka.
Co DPIA musi zawierać:
- Opis operacji przetwarzania — co, dlaczego, kto, gdzie
- Ocena niezbędności i proporcjonalności — czy cel można osiągnąć przy mniejszej ingerencji w prywatność?
- Ocena ryzyka dla praw i wolności osób, których dane dotyczą
- Środki zarządzania ryzykiem — techniczne i organizacyjne
- Jeśli ryzyko rezydualne nadal jest wysokie → konsultacja z organem nadzorczym (np. Urzędem Ochrony Danych Osobowych)
EU AI Act i GDPR — dwie warstwy compliance
Od sierpnia 2025 roku weszły w życie obowiązki dla modeli GPAI (General Purpose AI) w ramach EU AI Act. Dla firm wdrażających (deployers) obowiązują wymogi wynikające z artykułu 26 — zwłaszcza w odniesieniu do systemów AI wysokiego ryzyka.
Ważna uwaga: EU AI Act i GDPR nie powielają się wzajemnie, lecz się uzupełniają. GDPR reguluje ochronę danych osobowych. EU AI Act reguluje ryzyka systemów AI — w tym sytuacje, w których AI podejmuje lub wpływa na decyzje dotyczące ludzi. Jeśli wasz system LLM pomaga podejmować decyzje w obszarze HR, kredytów, dostępu do usług lub klasyfikacji bezpieczeństwa, może zostać zakwalifikowany jako AI wysokiego ryzyka — a wówczas macie obowiązki wynikające z obydwu rozporządzeń jednocześnie.
Szczegółowy przegląd konkretnych obowiązków dla firm znajdziecie w artykule o EU AI Act i obowiązkach firmy.
Praktyczna checklista compliance
Podsumowanie w formie listy kontrolnej przed wdrożeniem LLM nad danymi firmowymi:
- DPA z każdym dostawcą LLM — podpisana, nie tylko odkliknięta; obejmuje również podpodmioty przetwarzające
- Podstawa prawna udokumentowana — LIA dla uzasadnionego interesu, zgoda gdy wymagana; zapisana, nie tylko w głowie
- Transfer danych poza EOG zabezpieczony — SCC lub odpowiednik, jeśli dostawca działa na serwerach w USA
- PII scrubbing — wdrożony przynajmniej dla logów; dla dokumentów tam, gdzie jest technicznie możliwy
- Polityka data minimization — okresy retencji dla logów, konwersacji i embeddingów zdefiniowane i egzekwowane
- DPIA — przeprowadzona dla przypadków użycia wysokiego ryzyka; wyniki udokumentowane
- Techniczne i organizacyjne środki bezpieczeństwa — szyfrowanie w transporcie i w spoczynku, kontrola dostępu, plan reagowania na incydenty
- Rejestr czynności przetwarzania (art. 30 GDPR) — system LLM musi być ujęty w Records of Processing Activities
- Ocena pod kątem EU AI Act — czy wasz system to AI wysokiego ryzyka? jeśli tak, obowiązki zgodnie z art. 26
Najczęstsze pytania
Czy potrzebny jest do tego prawnik, czy poradzimy sobie wewnętrznie?
Zależy od zakresu. Dla prostego wewnętrznego chatbota opartego na publicznej dokumentacji technicznej bez danych osobowych wystarczy wewnętrzna ocena z DPO. Gdy przetwarzacie szczególne kategorie danych, obsługujecie transfer poza EOG lub wasz system wpływa na decyzje dotyczące ludzi, zewnętrzny prawnik wyspecjalizowany w ochronie danych i AI się opłaca — kary za naruszenie GDPR sięgają 4% globalnego obrotu lub 20 milionów euro.
Czy mogę używać zanonimizowanych danych i ominąć GDPR?
Jeśli osiągnęliście prawdziwą anonimizację — tzn. danych nie można przypisać osobie fizycznej nawet pośrednio — GDPR nie ma do nich zastosowania. W praktyce jest to trudne. LLM rzadko kiedy spełniają standard prawdziwej anonimizacji; pseudonimizacja (zastąpienie tokenem, który można zrekonstruować) nie wystarczy. Skonsultujcie się z DPO, czy wasza metoda rzeczywiście spełnia standard anonimizacji.
Czy musimy przeprowadzać DPIA dla każdego projektu LLM?
Nie dla każdego. DPIA jest obowiązkowa przy wysokim ryzyku dla praw osób — typowo przy szczególnych kategoriach danych, zautomatyzowanym podejmowaniu decyzji o skutkach dla ludzi lub rozległym monitorowaniu. Dla wewnętrznego helpdesku opartego na instrukcjach technicznych bez danych osobowych DPIA nie jest obowiązkowa. Zalecamy przeprowadzenie przynajmniej krótkiej wewnętrznej oceny ryzyka i udokumentowanie decyzji.
Co się stanie, jeśli dostawca LLM zmieni warunki i zacznie trenować na naszych danych?
To realne ryzyko. Dlatego DPA musi zawierać zakaz wykorzystywania waszych danych do treningu oraz prawo do audytu. Śledźcie zmiany w Terms of Service i ustalcie proces przeglądu co najmniej raz w roku. Jeśli dostawca zmieni warunki w sposób sprzeczny z DPA, macie prawo odstąpić od umowy i żądać usunięcia danych.
Czy LLM on-prem jest automatycznie zgodny z GDPR?
Nie automatycznie. On-prem eliminuje ryzyko transferu danych do zewnętrznego podmiotu przetwarzającego, ale nadal musicie mieć zdefiniowaną podstawę prawną, politykę data minimization, okresy retencji i środki techniczne. Różnica polega na tym, że problemy rozwiązujecie wewnętrznie — a nie za pośrednictwem DPA z zewnętrznym dostawcą.
*GDPR i LLM nad danymi firmowymi to nie projekt na jeden weekend, ale nie może też być powodem do zablokowania startu. Większość firm, z którymi pracujemy, potrzebuje przede wszystkim ustrukturyzowanego przeglądu tego, co mają zabezpieczone, a czego nie — nie dziesiątek godzin konsultacji prawnych. Jeśli chcecie przejść przez tę checklistę w odniesieniu do konkretnego wdrożenia w waszej firmie, jesteśmy do dyspozycji na wstępną konsultację.*