Wyciek danych przez LLM: jak chronić dane firmowe i klientów

Większość rozmów o bezpieczeństwie AI zatrzymuje się na „nie wklejaj poufnych danych do publicznego czatu”. To prawda, ale to dopiero pierwszy, najprostszy wektor. W systemach produkcyjnych — asystentach z bazą wiedzy, agentach z dostępem do CRM, automatyzacjach obsługi — dane wyciekają w sposób mniej oczywisty: przez kontekst, który model ma w pamięci, przez logi, które ktoś kiedyś włączył „na czas debugowania”, przez warunki licencyjne dostawcy modelu. Ten artykuł rozkłada cztery realne wektory wycieku i opisuje konkretną obronę dla każdego z nich. Nie obiecujemy „pełnej szczelności” — w bezpieczeństwie taka obietnica jest sygnałem ostrzegawczym. Opisujemy, jak zredukować ryzyko do poziomu, który da się udokumentować i obronić.

Prompt injection to wstrzyknięcie instrukcji do treści, którą model przetwarza jako dane wejściowe. W systemie z bazą wiedzy model widzi w swoim kontekście prompt systemowy, pobrane fragmenty dokumentów i — czasem — dane innych użytkowników. Atakujący, który nakłoni model do „przeczytania na głos” tego kontekstu, wydobywa rzeczy, których nigdy nie powinien zobaczyć: treść instrukcji systemowych, fragmenty cudzych danych, strukturę wewnętrznych źródeł.

Najgroźniejsza odmiana to injection pośredni: złośliwa instrukcja nie jest wpisywana w czacie, lecz ukryta w dokumencie, który system sam pobiera do kontekstu (e-mail, plik PDF, strona WWW). Model traktuje ją jak część zadania. Dlatego sama walidacja tego, co wpisuje użytkownik, nie wystarcza — trzeba też kontrolować to, co system wciąga z zewnątrz.

Obrona ma trzy warstwy. Pierwsza: prompt systemowy nigdy nie zawiera sekretów ani danych, których ujawnienie boli — klucze i dane wrażliwe trzymamy poza kontekstem modelu. Druga: guardrails na wejściu wykrywają próby manipulacji instrukcją (wzorce „zignoruj poprzednie polecenia”, próby zmiany języka jako kamuflażu). Trzecia: izolacja per-rola i per-tenant, żeby nawet udany injection nie sięgał poza dane, do których użytkownik i tak ma prawo. Szczegółową listę testów opisujemy w artykule o audycie bezpieczeństwa asystenta AI, a architekturę uprawnień — w tekście o bezpieczeństwie agentów AI.

To najczęstszy wyciek, jaki widzimy w praktyce — i najmniej spektakularny. Dane osobowe trafiają do systemu zupełnie legalnie: klient pisze imię i numer sprawy, pracownik wkleja fragment umowy. Problem zaczyna się dalej, gdy te dane wędrują tam, gdzie nikt ich nie planował: do zewnętrznego API modelu w postaci jawnej, do logów aplikacji, do tabeli „historia konwersacji” bez polityki retencji.

Logi są tu szczególnie podstępne. Observability jest potrzebna do diagnozowania problemów, więc ktoś włącza pełne logowanie treści zapytań „tymczasowo” — i zostaje tak na miesiące. Po pół roku masz repozytorium PII bez podstawy prawnej, bez retencji i bez mechanizmu usuwania na żądanie, którego wymaga RODO.

Obrona to maskowanie PII przed modelem i przed zapisem do logu. W naszym podejściu zapytanie przechodzi przez warstwę pseudonimizacji, zanim trafi do LLM: imiona, numery PESEL, e-maile i numery kont zostają zastąpione tokenami, a oryginały — jeśli w ogóle są potrzebne — zostają po stronie, którą kontrolujesz. Logi zapisują metadane operacyjne (czas, status, koszt tokenów), nie treść w postaci czystej. Jak przygotować dane firmowe tak, żeby ta warstwa działała od początku, opisujemy w tekście o przygotowaniu danych pod AI.

Trzeci wektor jest umowny, nie techniczny — i właśnie dlatego łatwo go przeoczyć. Gdy wysyłasz zapytanie do zewnętrznego API modelu, kluczowe pytanie brzmi: co dostawca robi z tymi danymi po przetworzeniu? Czy są przechowywane? Czy mogą trafić do zbioru treningowego kolejnej wersji modelu? Czy są przetwarzane poza Europejskim Obszarem Gospodarczym?

To pytania o data-residency i retencję, a odpowiedzi kryją się w warunkach licencyjnych, nie w dokumentacji technicznej. Różnica między „API do zadań biznesowych z gwarancją zero-retention” a „darmowym czatem konsumenckim, który uczy się na rozmowach” jest fundamentalna z perspektywy RODO i często decyduje o tym, czy w ogóle wolno Ci użyć danego dostawcy do danych klientów.

Tu wybór architektury robi największą różnicę. Self-hosting modelu — uruchomienie go na własnej lub kontrolowanej infrastrukturze — eliminuje ten wektor u źródła: dane nie opuszczają Twojego środowiska, więc pytanie „co dostawca z nimi robi” znika. Kosztem jest utrzymanie i zwykle niższa surowa jakość najlepszych modeli. Kompromis i kryteria decyzji rozkładamy w artykule o self-hostingu LLM a RODO.

Czwarty wektor działa w drugą stronę: nie chodzi o to, co wsadzasz do modelu, lecz o to, co model oddaje użytkownikowi. System z bazą wiedzy może w odpowiedzi sięgnąć po dokument, do którego pytający nie ma uprawnień — i streścić jego treść, omijając całą kontrolę dostępu zbudowaną na poziomie aplikacji. Albo model „uzupełni” odpowiedź danymi, które zapamiętał z poprzedniej rozmowy innego użytkownika w źle odizolowanej sesji.

Obrona łączy kontrolę dostępu z guardrails na wyjściu. Filtrowanie uprawnień musi działać na poziomie pobierania kontekstu (model widzi tylko fragmenty, do których pytający ma prawo), nie dopiero na poziomie odpowiedzi. Na samym wyjściu druga warstwa guardrails skanuje odpowiedź pod kątem wzorców danych wrażliwych, zanim trafi do użytkownika. Ta sama warstwa pilnuje, by model nie zacytował sekretu ani PII nawet wtedy, gdy z jakiegoś powodu znalazły się w kontekście.

Cztery wektory wymagają czterech różnych warstw obrony. Poniższa tabela zestawia, co przed czym chroni — i pokazuje, dlaczego pojedynczy środek nie wystarcza.

Żaden wiersz nie pokrywa pozostałych. Self-hosting (wiersz 3) nie chroni przed prompt injection (wiersz 1). Maskowanie PII (wiersz 2) nie zatrzyma odpowiedzi cytującej cudzy dokument (wiersz 4). Bezpieczeństwo to suma warstw — i właśnie dlatego audyt sprawdza każdą osobno.

Cztery warstwy techniczne działają tylko wtedy, gdy stoi za nimi decyzja organizacyjna: które dane wolno w ogóle przekazać do modelu, w jakiej formie i przez którego dostawcę. To domena governance danych do AI — klasyfikacji danych, rejestru przepływów i przypisania odpowiedzialności. Bez niej każda warstwa techniczna jest konfigurowana ad hoc i z czasem dryfuje.

Dla danych klientów warto sprawdzić, czy przetwarzanie wymaga DPIA — oceny skutków dla ochrony danych. Wynik audytu wektorów wycieku (z tabeli powyżej) naturalnie zasila taką ocenę: pokazuje, jakie ryzyko istnieje i jak zostało ograniczone. Obowiązki dokumentacyjne na 2026 rok, łączące RODO z AI Act, opisujemy w artykule o obowiązkach firm wobec AI Act i RODO.

Praktyczny porządek wdrożenia jest taki: najpierw klasyfikacja danych i decyzja o dostawcy (governance), potem maskowanie PII i kontrola dostępu (warstwy techniczne, które trzeba zbudować raz a dobrze), na końcu guardrails i audyt jako warstwa weryfikująca. Próba zaczynania od guardrails na systemie, który już wysyła surowe PII do zewnętrznego API, to leczenie objawu zamiast przyczyny.

To konieczne, ale dalece niewystarczające dla systemu produkcyjnego. Gdy budujesz asystenta z bazą wiedzy lub agenta z dostępem do CRM, dane trafiają do modelu w sposób zaprojektowany, nie przypadkowy — i tam właśnie potrzebujesz maskowania PII, kontroli dostępu i polityki retencji. Zasada „nie wklejaj poufnych danych” chroni przed jednym wektorem z czterech.

Zamyka jeden konkretny wektor: dane nie trafiają do zewnętrznego dostawcy, więc znika ryzyko retencji i treningu na Twoich danych. Nie eliminuje jednak prompt injection, wycieku PII do logów ani ujawnienia danych spoza uprawnień w odpowiedzi — te zależą od architektury, nie od miejsca hostingu. Self-hosting upraszcza compliance RODO, ale audyt pozostałych warstw jest konieczny niezależnie od wyboru infrastruktury.

To warstwa, która przechwytuje zapytanie, zanim trafi do LLM, i zastępuje dane osobowe (imiona, PESEL, e-maile, numery kont) tokenami zastępczymi. Model pracuje na zanonimizowanej treści, a oryginalne dane — jeśli są w ogóle potrzebne do odpowiedzi — pozostają po stronie, którą kontrolujesz. Dzięki temu nawet wyciek kontekstu lub log z pełną treścią nie ujawnia realnych danych osobowych.

Odpowiedź jest w warunkach licencyjnych usługi, nie w dokumentacji technicznej — szukaj zapisów o retencji danych, treningu i lokalizacji przetwarzania (data-residency). Płatne API biznesowe zwykle oferują zero-retention i wykluczenie z treningu; darmowe usługi konsumenckie często nie. Jeśli przetwarzasz dane klientów, traktuj brak jednoznacznej gwarancji zero-retention jako brak zgody na użycie tego dostawcy.

Tyle, ile masz aktywnych wektorów. Jeśli system korzysta z zewnętrznego API i przetwarza PII klientów, w grze są wszystkie cztery — i wtedy potrzebujesz maskowania, guardrails, kontroli dostępu oraz decyzji o retencji u dostawcy lub self-hostingu. Liczby kosztów i czasu zależą od skali, więc podajemy je w widełkach dopiero po inwentaryzacji danych; punktem wyjścia jest klasyfikacja, która pokazuje, które wektory w ogóle Cię dotyczą.