GDPR AI: kwestie zgodności z EU RODO przy wyborze dostawcy LLM

Co jest danymi osobowymi w systemach LLM

W EU GDPR dane osobowe to każda informacja o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej, w tym identyfikatory pośrednie i „identyfikatory internetowe” (Art. 4(1)).

W praktyce „GDPR data” w systemach LLM może pojawić się w kilku warstwach:

• Prompty, komunikaty systemowe i wejścia użytkownika
  Wolny tekst często zawiera imiona i nazwiska, e-maile, identyfikatory zamówień, treści zgłoszeń, kontekst HR lub korespondencję z klientem. Nawet jeśli nie planujesz przesyłać danych osobowych, użytkownik może je wkleić do automatyzacji.

• Historia rozmów i logi sesji
  Historia czatu staje się zbiorem danych osobowych, jeśli rozmowa je zawiera. Dostawcy mogą przetwarzać i przechowywać określone dane w celach operacyjnych (np. monitoring nadużyć), a część produktów ma ustawienia retencji. Przykładowo OpenAI opisuje kontrolę retencji w środowiskach biznesowych i wskazuje, że usunięte konwersacje są usuwane w ciągu 30 dni (z wyjątkami prawnymi).

• Embeddingi wektorowe i ryzyko reidentyfikacji
  Embeddingi są pochodną tekstu. Ryzyko GDPR zależy od możliwości identyfikacji: jeżeli embedding można powiązać z osobą (bezpośrednio lub przez dodatkowe informacje), należy traktować go jak dane osobowe. Zgodnie z logiką GDPR pseudonimizacja to środek ograniczający ryzyko, a nie „wyjście” spod GDPR.

Podstawa prawna przetwarzania danych osobowych

GDPR wymaga co najmniej jednej podstawy prawnej z Art. 6. Dla LLM w narzędziach wewnętrznych i produktach zwykle rozważa się:

• Niezbędność do wykonania umowy (Art. 6(1)(b))
  Działa, gdy przetwarzanie jest obiektywnie konieczne do realizacji umowy z użytkownikiem. Ryzyko: szeroka retencja, analityka czy „miłe dodatki” często nie są „niezbędne”.

• Prawnie uzasadniony interes (Art. 6(1)(f))
  Często stosowany w automatyzacji wsparcia i produktywności, ale wymaga testu równowagi i dokumentacji konieczności/impactu.

• Zgoda (Art. 6(1)(a))
  Zwykle wysokie ryzyko: zgoda musi być dobrowolna, konkretna, świadoma i łatwa do wycofania. W kontekście pracowniczym nierównowaga sił często podważa dobrowolność (to kwestia interpretacji prawnej — warto skonfrontować z prawnikiem i wytycznymi organu).

• Dane szczególnych kategorii (Art. 9)
  Jeśli w promptach/RAG pojawiają się m.in. dane zdrowotne czy poglądy polityczne, wchodzą ograniczenia Art. 9 i potrzebujesz zarówno podstawy z Art. 6, jak i przesłanki z Art. 9.

• Administrator vs podmiot przetwarzający
  W typowym wdrożeniu to Twoja organizacja jest administratorem (controller) dla danych w promptach i w Twoim produkcie. Dostawca LLM bywa podmiotem przetwarzającym (processor) na podstawie DPA — ale trzeba to potwierdzić dla konkretnego wariantu usługi.

  Przykład: DPA OpenAI stwierdza, że OpenAI działa jako Data Processor dla „Customer Data” przetwarzanych w celu świadczenia usług.
  Przykład: warunki Gemini API dla „Paid Services” wskazują przetwarzanie na podstawie „Data Processing Addendum for Products Where Google is a Data Processor.”

• Wygenerowane odpowiedzi zawierające lub wnioskujące dane osobowe
  Model może odtworzyć dane z promptu, z RAG lub zasugerować dane na podstawie kontekstu. To nadal element tego samego procesu przetwarzania i musi być objęty celem, podstawą prawną, bezpieczeństwem oraz retencją.

• Błędne założenie: „LLM nic nie zapisuje”
  „Bezstanowy model” nie oznacza, że „nigdzie nie ma przechowywania danych”. Nawet jeśli model bazowy nie „zapamiętuje”, warstwy usługowe mogą przechowywać stan (wątki, pliki, logi bezpieczeństwa). Microsoft opisuje Azure Direct Models jako „stateless” i wskazuje, że prompty/odpowiedzi nie są przechowywane w modelu — ale ta sama dokumentacja opisuje funkcje przechowywania danych oraz magazyn monitoringu nadużyć (szczególnie dla Global/DataZone).

Minimalizacja danych i ograniczenie celu

GDPR wymaga zdefiniowania celu i ograniczenia przetwarzania do tego, co niezbędne (purpose limitation + data minimisation).

Najczęstsze ryzyka w LLM:

• Prompty „na wolno” sprzyjają nadmiarowemu zbieraniu danych
  Pracownicy wklejają całe wątki e-mail, rekordy CRM lub notatki HR „żeby model lepiej zrozumiał”.

• Długość kontekstu, pamięć i trwałość muszą być projektowane
  Włączona pamięć, przechowywanie wątków czy utrzymywanie stanu do debugowania zwiększa zakres przetwarzania i retencji.

• Ryzyko użycia wtórnego: trening, analityka, monitoring
  Nawet gdy dostawca deklaruje brak treningu na danych biznesowych, mogą istnieć logi dla monitoringu nadużyć/bezpieczeństwa.
  Przykład: polityka „abuse monitoring” Gemini API mówi o retencji promptów/kontekstu/odpowiedzi przez 55 dni w tym celu oraz o braku użycia tych danych do trenowania/fine-tuning.

• „Drift celu” w ogólnych wdrożeniach AI
  Narzędzie do streszczania zgłoszeń staje się analizą insightów, a następnie zbiorem do fine-tuningu — jeśli governance tego nie zatrzyma.

Trening modeli, retencja promptów i ponowne użycie danych

W ocenie GDPR warto rozdzielić trzy pytania:

A) Czy dane klienta są używane do treningu / ulepszania?

• OpenAI (business/API): OpenAI deklaruje, że domyślnie nie trenuje na danych wej./wyj. biznesowych (ChatGPT Business/Enterprise/API), chyba że klient się zgodzi (opt-in).

• Microsoft Azure Direct Models: prompty/odpowiedzi „nie są używane do trenowania, ponownego trenowania ani ulepszania modeli bazowych.”

• Amazon Bedrock: AWS wskazuje, że Bedrock nie używa promptów/odpowiedzi do trenowania modeli AWS i nie dystrybuuje ich stronom trzecim.

• Gemini API: dla „Paid Services” Google wskazuje brak użycia promptów/odpowiedzi do ulepszania produktów; dane monitoringu nadużyć nie służą do trenowania/fine-tuning.

B) Jak długo prompty/odpowiedzi są przechowywane?

Retencję trzeba mapować w trzech miejscach:

• logi dostawcy (monitoring nadużyć/operacje),

• stan aplikacji (wątki, przechowywane odpowiedzi),

• Twoje własne systemy (historia czatu, analityka, cache RAG).

Przykłady z dokumentacji:

• Gemini API: retencja dla monitoringu nadużyć: 55 dni.

• OpenAI API (stan aplikacji): dokumentacja opisuje domyślną retencję stanu aplikacji w Responses API 30 dni; przy Zero Data Retention store jest traktowane jak false.

• OpenAI (logi): OpenAI wskazuje, że po 30 dniach dane wej./wyj. API są usuwane z logów (z wyjątkami prawnymi).

• Azure Direct Models: dokumentacja opisuje magazyn monitoringu nadużyć, ale w cytowanym fragmencie nie podaje konkretnego okresu retencji.

C) Prawo do usunięcia vs modele trenowane

Jeśli dane osobowe były użyte do treningu, usunięcie wpływu z wag modelu jest trudne technicznie. To napięcie prawno-techniczne warto ujawniać w DPIA, zwłaszcza przy fine-tuning na danych osobowych.

D) Fine-tuning na danych osobowych

Microsoft wskazuje m.in., że dane do fine-tuning nie są używane do trenowania modeli bazowych bez instrukcji/zgody oraz że modele fine-tuned są „exclusive” dla klienta i możliwe do usunięcia.
Warunki Gemini API opisują retencję danych związanych z tuned models i usunięcie danych po usunięciu tuned model.
Mimo to fine-tuning na danych osobowych zazwyczaj zwiększa ryzyko i często prowadzi do konieczności DPIA oraz rygorystycznej minimalizacji.

Trening modeli, retencja promptów i ponowne użycie danych

W ocenie GDPR warto rozdzielić trzy pytania:

A) Czy dane klienta są używane do treningu / ulepszania?

• OpenAI (business/API): OpenAI deklaruje, że domyślnie nie trenuje na danych wej./wyj. biznesowych (ChatGPT Business/Enterprise/API), chyba że klient się zgodzi (opt-in).

• Microsoft Azure Direct Models: prompty/odpowiedzi „nie są używane do trenowania, ponownego trenowania ani ulepszania modeli bazowych.”

• Amazon Bedrock: AWS wskazuje, że Bedrock nie używa promptów/odpowiedzi do trenowania modeli AWS i nie dystrybuuje ich stronom trzecim.

• Gemini API: dla „Paid Services” Google wskazuje brak użycia promptów/odpowiedzi do ulepszania produktów; dane monitoringu nadużyć nie służą do trenowania/fine-tuning.

B) Jak długo prompty/odpowiedzi są przechowywane?

Retencję trzeba mapować w trzech miejscach:

• logi dostawcy (monitoring nadużyć/operacje),

• stan aplikacji (wątki, przechowywane odpowiedzi),

• Twoje własne systemy (historia czatu, analityka, cache RAG).

Przykłady z dokumentacji:

• Gemini API: retencja dla monitoringu nadużyć: 55 dni.

• OpenAI API (stan aplikacji): dokumentacja opisuje domyślną retencję stanu aplikacji w Responses API 30 dni; przy Zero Data Retention store jest traktowane jak false.

• OpenAI (logi): OpenAI wskazuje, że po 30 dniach dane wej./wyj. API są usuwane z logów (z wyjątkami prawnymi).

• Azure Direct Models: dokumentacja opisuje magazyn monitoringu nadużyć, ale w cytowanym fragmencie nie podaje konkretnego okresu retencji.

C) Prawo do usunięcia vs modele trenowane

Jeśli dane osobowe były użyte do treningu, usunięcie wpływu z wag modelu jest trudne technicznie. To napięcie prawno-techniczne warto ujawniać w DPIA, zwłaszcza przy fine-tuning na danych osobowych.

D) Fine-tuning na danych osobowych

Microsoft wskazuje m.in., że dane do fine-tuning nie są używane do trenowania modeli bazowych bez instrukcji/zgody oraz że modele fine-tuned są „exclusive” dla klienta i możliwe do usunięcia.
Warunki Gemini API opisują retencję danych związanych z tuned models i usunięcie danych po usunięciu tuned model.
Mimo to fine-tuning na danych osobowych zazwyczaj zwiększa ryzyko i często prowadzi do konieczności DPIA oraz rygorystycznej minimalizacji.

AI Act vs GDPR: co się zmienia, a co nie

EU AI Act i GDPR regulują różne obszary:

• GDPR: przetwarzanie danych osobowych.

• AI Act: ramy ryzyka dla systemów AI (w tym zasady dla GPAI), zależne od kategorii i kontekstu użycia.

Wnioski „GDPR-first”:

• AI Act nie zastępuje GDPR — jeśli przetwarzasz dane osobowe, GDPR nadal obowiązuje.

• Nakładanie się obowiązków jest realne (governance, dokumentacja, ryzyko), ale wyzwalacze są inne.

• Podział ról: AI Act ma obowiązki dostawcy vs deployera; GDPR — administrator vs podmiot przetwarzający.

Najpopularniejsi dostawcy LLM — porównanie GDPR (tylko compliance, tylko źródła)

Uwaga zakresu: „Azure AI Foundry”, „AWS” i „Gemini” obejmują wiele usług. Poniżej ograniczam się do wskazanych wariantów: Foundry/Azure Direct Models (Global vs DataZone), OpenAI API (biznes), Amazon Bedrock, Gemini API (Paid Services).

Tabela porównawcza 
 

Checklista wdrożeniowa „GDPR-first” + tabela podsumowująca

Checklista (praktyczna, dla administratora danych)

1. Definicja celu (purpose limitation)
   Jednozdaniowy cel na funkcję LLM (np. „streszczać zgłoszenia supportowe, aby skrócić czas obsługi”). Zakaz użycia wtórnego domyślnie.

2. Podstawa prawna (Art. 6)
   Udokumentuj wybór (umowa lub prawnie uzasadniony interes). Dla 6(1)(f) — test równowagi.

3. Klasyfikacja danych
   Zasady: co wolno wysyłać do LLM; brak danych szczególnych kategorii bez zgody i procedury. Zrób to z perspektywy GDPR IT (polityki + techniczne blokady).

4. Region + walidacja przepływów
   Udokumentuj routing/przetwarzanie (Global/DataZone, cross-Region inference, transient cache). Nie traktuj „EU hosting” jako fakt bez źródeł.

5. DPA + podwykonawcy (Art. 28)
   Sprawdź klauzule Art. 28 i zasady subprocessorów.
   Włącz powiadomienia o zmianach podwykonawców, jeśli dostępne.

6. Retencja i usuwanie
   Oddziel: retencję dostawcy, stan aplikacji, Twoje magazyny (historia/embeddingi/analiza). Preferuj konfiguracje minimalizujące retencję po stronie dostawcy, gdy to możliwe.

7. Kontrola dostępu, logowanie i bezpieczeństwo
   Least privilege, rotacja kluczy, izolacja tenantów/projektów, monitoring. Pamiętaj: środki techniczne pomagają, ale nie „kasują” analizy transferu Schrems II.

8. Prawa osób, których dane dotyczą
   Proces DSAR musi obejmować: Twoją historię czatów/embeddingi, logi dostawcy (tam, gdzie masz wpływ), systemy RAG. Przykładowo DPA OpenAI zawiera postanowienia o wsparciu w realizacji praw.