Ciche wycieki – jak modele językowe mimowolnie zdradzają twoje sekrety
Model językowy może ujawnić poufną informację w odpowiedzi, która wygląda jak zwykła pomoc. Źródłem takiego „cichego wycieku” bywa fragment zapamiętany podczas treningu, ale też dokument, do którego aplikacja uzyskała dostęp w trakcie rozmowy. Nie oznacza to, że każdy chatbot pokazuje innym użytkownikom twoje wiadomości. Ryzyko zależy między innymi od tego, jakie dane otrzymuje, jak działa usługa i czy prawidłowo ograniczono dostęp do informacji.
Co może wyciec i dlaczego trudno to zauważyć?
Sekretem w rozmowie z modelem nie jest wyłącznie hasło. Może nim być numer dokumentu, informacja o stanie zdrowia, treść umowy, nieopublikowany plan projektu, kod źródłowy albo klucz API dający dostęp do usługi. Czasem wystarczy krótki fragment odpowiedzi, by ujawnić nazwisko klienta, warunki negocjacji czy szczegół wewnętrznej dokumentacji.
Taki wyciek nie musi mieć postaci komunikatu „oto poufne dane”. Asystent może przytoczyć fragment dokumentu jako uzasadnienie odpowiedzi lub wykorzystać szczegół, którego odbiorca nie miał prawa znać. Łatwo wtedy skupić się na tym, czy odpowiedź jest przydatna, i przeoczyć pochodzenie zawartych w niej informacji.
OWASP, organizacja zajmująca się bezpieczeństwem aplikacji, wymienia ujawnianie informacji wrażliwych wśród zagrożeń związanych z aplikacjami opartymi na modelach językowych. Istotne jest tu słowo „aplikacje”: odpowiedź powstaje nie tylko dzięki samemu modelowi. Znaczenie mają również podłączone bazy dokumentów, mechanizmy wyszukiwania, ustawienia uprawnień oraz sposób zapisywania rozmów.
Dane z treningu a dane z bieżącej rozmowy
Aby zrozumieć ryzyko, trzeba rozdzielić dwa źródła informacji. Pierwszym są dane użyte do trenowania lub dostrajania modelu. Model uczy się na ich podstawie tworzyć odpowiedzi. Nie działa jak wyszukiwarka przechowująca każde zdanie w osobnym rekordzie, ale może zapamiętać i odtworzyć niektóre fragmenty materiału. Jeżeli w danych znalazła się poufna treść, jej pojawienie się w późniejszej odpowiedzi staje się możliwe. Badania nad zapamiętywaniem i wydobywaniem danych z modeli pokazują, że nie jest to wyłącznie teoretyczny scenariusz; nie pozwalają jednak uznać, że dowolny sekret da się w ten sposób odzyskać.
Drugim źródłem są informacje udostępnione aplikacji podczas jej używania: tekst wpisany w oknie rozmowy, załączony plik, wcześniejsze wiadomości lub dokument pobrany z firmowej bazy. Model nie musi pamiętać takiej treści z treningu, żeby umieścić ją w odpowiedzi — wystarczy, że aplikacja przekaże mu ją jako kontekst bieżącego zadania.
To rozróżnienie ma praktyczne znaczenie. Gdy wklejasz umowę do asystenta z prośbą o streszczenie, udostępniasz jej treść używanej usłudze. Nie wynika z tego automatycznie, że umowa trafi do treningu modelu albo zostanie pokazana obcej osobie. O tym, jak jest przetwarzana i przechowywana, decydują zasady oraz ustawienia konkretnej usługi. Z kolei nawet jeśli dostawca nie wykorzystuje rozmów do ulepszania modelu, trzeba nadal zadbać o bezpieczeństwo załączników, historii rozmów i połączonych źródeł danych.
Jak aplikacja może pokazać dokument niewłaściwej osobie?
Asystent podłączony do firmowej bazy wiedzy często wyszukuje materiały potrzebne do odpowiedzi. To wygodne: zamiast ręcznie przeglądać pliki, pytasz o procedurę i dostajesz wyjaśnienie oparte na odpowiednim dokumencie. Problem powstaje, gdy wyszukiwanie lub przekazywanie znalezionych treści nie respektuje uprawnień osoby zadającej pytanie.
Wyobraź sobie, że pracownik pyta o zasady rozliczania projektu. Aplikacja znajduje zarówno ogólną instrukcję, jak i poufny dokument dotyczący innego zespołu. Jeśli oba pliki zostaną przekazane modelowi bez sprawdzenia, czy pytający może je zobaczyć, odpowiedź może zawierać fragment tego drugiego. Model nie musi „włamywać się” do bazy. Korzysta z materiału, który otrzymał od aplikacji.
Podobny problem może dotyczyć historii rozmowy lub treści pobieranych z różnych narzędzi. Jeżeli aplikacja pomyli kontekst użytkowników albo połączy informacje bez odpowiedniej kontroli, prywatny szczegół może znaleźć się w nieuprawnionej odpowiedzi. Dlatego ograniczenie dostępu musi działać przed przekazaniem danych modelowi, a nie polegać wyłącznie na poleceniu, by „nie ujawniał poufnych informacji”.
Szczególnym przypadkiem są złośliwe instrukcje ukryte w przetwarzanym materiale. Dokument lub strona internetowa może zawierać tekst nakazujący asystentowi zignorowanie zadania i ujawnienie innych danych. Nazywa się to wstrzyknięciem instrukcji, czyli prompt injection. Taki tekst nie powinien mieć uprawnień użytkownika ani administratora, ale niewłaściwie zabezpieczona aplikacja może potraktować go jak polecenie. To kolejny powód, by kontrolować zarówno źródła danych, jak i zakres działań dostępnych asystentowi.
Czy samo wpisanie sekretu oznacza wyciek?
Nie. Przekazanie danych usłudze, ich zapisanie i ujawnienie osobie nieuprawnionej to różne zdarzenia. Kiedy wpisujesz informację do chatbota, trafia ona do systemu obsługującego rozmowę. To, czy i jak długo będzie przechowywana oraz czy może zostać wykorzystana do ulepszania usługi, zależy od jej zasad i wybranych ustawień. Wyciek w znaczeniu ujawnienia następuje wtedy, gdy informacja staje się dostępna komuś, kto nie powinien jej otrzymać.
Nie należy jednak czekać na dowód wycieku, by zastanowić się nad poufnością. Jeśli nie znasz zasad przetwarzania danych, rozsądniej nie przesyłać informacji, których ujawnienie miałoby poważne skutki. Dotyczy to zwłaszcza haseł, kluczy dostępu, danych pacjentów oraz niezanonimizowanych dokumentów klientów.
Ważne są także logi, czyli zapisy działania usługi. Mogą pomagać w wykrywaniu błędów i nadużyć, ale pełne treści rozmów zapisane bez potrzeby tworzą kolejne miejsce przechowywania danych wrażliwych. OWASP zaleca ograniczanie takich zapisów do niezbędnego zakresu oraz maskowanie lub anonimizowanie treści, jeśli muszą być zachowane.
Nie ma też podstaw, by na podstawie pojedynczego badania lub opisu incydentu określać, jak często chatboty ujawniają prywatne dane polskich użytkowników. Ryzyko jest rzeczywiste, lecz jego skala zależy od badanego narzędzia, rodzaju danych i zabezpieczeń. Liczba dotycząca jednej usługi nie byłaby wiarygodnym wskaźnikiem dla wszystkich modeli.
Jak korzystać z asystenta, nie oddając mu zbędnych danych?
Najbezpieczniejsza praktyka polega na przekazywaniu tylko informacji potrzebnych do wykonania zadania. Jeśli chcesz poprawić styl pisma, zwykle nie musisz podawać prawdziwego nazwiska adresata, numeru sprawy ani kwoty widniejącej w umowie. Asystent może pracować na wersji, w której takie szczegóły zastąpiono neutralnymi oznaczeniami.
- Usuń dane identyfikujące przed wklejeniem tekstu: nazwiska, adresy, numery dokumentów i nazwy poufnych projektów zastąp oznaczeniami, których znaczenie znasz tylko ty.
- Nie przesyłaj danych dostępowych, takich jak hasła i klucze API. Jeśli potrzebujesz pomocy z konfiguracją, pokaż przykład bez działających sekretów.
- Sprawdź zasady usługi: dowiedz się, jak wykorzystuje rozmowy, jak długo je przechowuje i czy pozwala wyłączyć użycie danych do ulepszania modelu.
- Kontroluj gotową odpowiedź przed jej udostępnieniem. Streszczenie lub projekt wiadomości również może zawierać poufny fragment zaczerpnięty z materiału wejściowego.
Anonimizacja wymaga odrobiny uwagi. Zastąpienie samego nazwiska może nie wystarczyć, jeśli pozostałe szczegóły jednoznacznie wskazują osobę lub firmę. W dokumentach służbowych warto więc sprawdzić także adresy, stanowiska, daty, charakterystyczne opisy zdarzeń i nazwy plików. Celem nie jest utrudnienie modelowi pracy, lecz pozostawienie mu wyłącznie kontekstu potrzebnego do odpowiedzi.
Jeżeli zadanie wymaga użycia prawdziwych danych wrażliwych, wybór narzędzia powinien wynikać z zasad obowiązujących w twojej organizacji oraz warunków konkretnej usługi. Publicznie dostępny asystent i zatwierdzone środowisko firmowe mogą różnić się sposobem zarządzania dostępem i przechowywania informacji; samej etykiety „firmowy” nie należy jednak traktować jako gwarancji bezpieczeństwa.
Co powinni zabezpieczyć twórcy aplikacji?
Użytkownik może ograniczyć to, co wpisuje, ale nie naprawi błędów w aplikacji pobierającej dokumenty. Za tę część odpowiada jej dostawca lub organizacja, która ją wdraża. Podstawą jest zasada najmniejszych uprawnień: asystent powinien otrzymać tylko informacje konieczne do wykonania danego zadania i dostępne dla konkretnego użytkownika. Uprawnienia trzeba sprawdzać przy pobieraniu dokumentów, zanim ich treść trafi do kontekstu modelu.
Drugą warstwą ochrony jest ograniczanie danych wrażliwych w materiałach używanych do treningu, dostrajania i bieżącego działania aplikacji. Obejmuje to usuwanie lub maskowanie danych, które nie są potrzebne, oraz kontrolę odpowiedzi przed jej pokazaniem. Pomocne jest też rozdzielenie zaufanych instrukcji aplikacji od treści pochodzących z dokumentów czy stron internetowych, które mogą zawierać złośliwe polecenia.
Żaden pojedynczy filtr nie rozwiązuje całego problemu. Instrukcja „nie ujawniaj sekretów” nie zastąpi kontroli dostępu do plików, a prawidłowe uprawnienia do plików nie zwalniają z ochrony logów i danych podawanych w rozmowie. Jeśli asystent pokaże informację, która wygląda na poufną, nie warto jej dalej rozpowszechniać. Zachowaj niezbędne informacje o zdarzeniu i zgłoś je administratorowi lub osobie odpowiedzialnej za bezpieczeństwo, aby można było ustalić, skąd pochodziła treść i kto mógł ją zobaczyć.