Czy można cofnąć wypłynięcie poufnych danych z systemu opartego na AI?

Czy można cofnąć wypłynięcie poufnych danych z systemu opartego na AI?

Nie da się z pewnością cofnąć wypłynięcia poufnych danych z systemu opartego na AI, jeśli nieuprawniona osoba zdążyła je zobaczyć, pobrać lub skopiować. Usunięcie informacji z aplikacji nie usuwa kopii z cudzych urządzeń. Można natomiast zatrzymać dalsze ujawnianie, ustalić skalę incydentu i ograniczyć jego skutki. To różnica między cofnięciem wycieku, które zwykle jest niemożliwe, a opanowaniem incydentu, na które nadal masz wpływ.

Co właściwie oznacza „wyciek z AI”?

System oparty na AI to często więcej niż sam model. Może obejmować okno rozmowy, historię zapytań, bazę dokumentów, wyszukiwarkę, integracje z pocztą lub firmowymi aplikacjami. Poufne informacje mogą zostać ujawnione na różnych etapach: gdy ktoś wpisze je do narzędzia, gdy aplikacja pobierze niewłaściwy dokument albo gdy odpowiedź trafi do osoby bez odpowiednich uprawnień.

Warto odróżnić wprowadzenie danych do usługi od ich udostępnienia nieuprawnionemu odbiorcy. Jeśli pracownik wkleił fragment umowy do zewnętrznego narzędzia AI, trzeba ustalić, kto jest dostawcą usługi, na jakich zasadach przetwarza wpisane treści i czy organizacja dopuszczała taki sposób pracy. Nie należy automatycznie zakładać, że fragment umowy stał się publiczny. Jednocześnie nie można uznać, że pozostał wyłącznie na komputerze pracownika.

Inny przypadek to chatbot, który zwrócił klientowi dane innego klienta, lub asystent z dostępem do plików, który przesłał je poza organizację. Tutaj informacja mogła już dotrzeć do odbiorcy, nad którym firma nie ma kontroli. Nawet jeśli usunie się błędną odpowiedź z historii rozmowy, odbiorca mógł ją wcześniej zapisać.

Dlaczego usunięcie danych nie cofa ujawnienia?

Dane mogą istnieć jednocześnie w bazie wiedzy, indeksie wyszukiwania, logach aplikacji, kopiach zapasowych i systemach połączonych z AI. Usunięcie dokumentu z jednego miejsca nie oznacza więc, że przestał być dostępny w pozostałych. Najważniejsze ograniczenie leży jednak poza systemem: nie da się technicznie zagwarantować usunięcia kopii, którą wykonała osoba trzecia.

Przykładowo firma może wyłączyć dostęp do wadliwie skonfigurowanego asystenta i usunąć z jego bazy plik zawierający cennik objęty tajemnicą handlową. Powstrzyma to kolejne odpowiedzi oparte na tym pliku, ale nie sprawi, że osoba, która wcześniej otrzymała cennik, zapomni jego treść lub utraci własny zapis.

Nie każdy incydent ma jednak identyczne skutki. Jeśli ujawniony został klucz API, można go unieważnić i wydać nowy. Stara kopia nadal będzie istnieć, lecz przestanie umożliwiać dostęp. W przypadku hasła można je zmienić. Przy ujawnieniu danych osobowych, wewnętrznych analiz czy warunków negocjowanej umowy taka techniczna „wymiana” informacji zwykle nie jest możliwa.

Co zrobić, gdy poufne dane mogły wypłynąć?

Reakcja powinna jednocześnie ograniczać dalszy dostęp i pozwalać ustalić, co zaszło. Pochopne skasowanie całej historii może utrudnić ocenę incydentu, dlatego działania porządkowe warto prowadzić z udziałem osób odpowiedzialnych za bezpieczeństwo i zgodnie z zasadami organizacji.

  1. Zatrzymaj źródło ujawniania. W zależności od sytuacji może to oznaczać czasowe wyłączenie chatbota, odłączenie integracji, zablokowanie udostępniania dokumentów lub ograniczenie konta. Ujawnione klucze i tokeny dostępu należy unieważnić, zamiast jedynie usuwać je z widocznego promptu.
  2. Ustal, co i komu mogło zostać pokazane. Sprawdź dostępne logi, historię zapytań, odpowiedzi systemu i uprawnienia użytkowników. Uwzględnij nie tylko główną aplikację, lecz także połączone repozytoria, eksporty i systemy przechowujące kopie.
  3. Ogranicz dostępność danych w zasobach, które kontrolujesz. Po zabezpieczeniu informacji potrzebnych do analizy usuń lub odizoluj dane z niewłaściwie udostępnionych baz, indeksów i innych miejsc. Ustal też z dostawcą usługi, jakie możliwości usunięcia i ograniczenia dalszego przetwarzania przewidują warunki korzystania z niej.
  4. Oceń skutki i obowiązki informacyjne. Inaczej postępuje się po ujawnieniu hasła, a inaczej po udostępnieniu danych klientów. W zależności od zawartości i okoliczności może być potrzebne poinformowanie zainteresowanych osób, kontrahentów lub właściwego organu oraz przeprowadzenie oceny prawnej.

Jeżeli nie da się od razu ustalić pełnego zakresu wycieku, nie warto odkładać zablokowania oczywistej drogi ujawniania do zakończenia całej analizy. Można najpierw ograniczyć działanie zagrożonej funkcji, a następnie uzupełniać ustalenia na podstawie zachowanych śladów.

Dlaczego system AI mógł ujawnić dane?

Jedną z przyczyn bywają zbyt szerokie uprawnienia. Asystent, który pomaga odpowiedzieć na pytanie o zamówienie, nie potrzebuje automatycznie dostępu do całej bazy klientów. Jeżeli aplikacja pobiera dokumenty bez sprawdzenia uprawnień osoby pytającej, model może wykorzystać w odpowiedzi treść, której ta osoba nie powinna zobaczyć. Kontrola dostępu musi zatem działać w aplikacji i źródłach danych, a nie zależeć wyłącznie od tego, czy model „odmówi” odpowiedzi.

Zagrożeniem jest też prompt injection, czyli próba nakłonienia modelu do niezamierzonego działania za pomocą spreparowanej instrukcji. Taka instrukcja może znajdować się nie tylko w pytaniu użytkownika, ale również w dokumencie lub na stronie, którą asystent ma przeczytać. Według OWASP manipulacja tego rodzaju może prowadzić między innymi do ujawnienia informacji. Nie ma przy tym niezawodnego zabezpieczenia opartego wyłącznie na samym modelu.

Osobny błąd to umieszczanie sekretów w instrukcjach systemowych, czyli tekstach określających sposób działania asystenta. Klucze API, dane uwierzytelniające czy szczegóły struktury uprawnień nie powinny trafiać do promptu jako metoda konfiguracji bezpieczeństwa. OWASP zaleca przechowywanie takich informacji poza promptem i egzekwowanie ograniczeń w pozostałych elementach aplikacji.

Jak zmniejszyć ryzyko kolejnego wycieku?

Najskuteczniejsze zabezpieczenia ograniczają zarówno ilość danych dostępnych dla AI, jak i działania, które system może wykonać. Model mający jedynie odczytać wskazany dokument stwarza inne ryzyko niż asystent, który potrafi przeszukiwać wszystkie firmowe pliki, pobierać załączniki i wysyłać wiadomości. Warto przyznawać mu tylko uprawnienia potrzebne do konkretnego zadania, a operacje o podwyższonym ryzyku, takie jak wysłanie pliku, uzależnić od zatwierdzenia przez człowieka.

Pomaga również ograniczenie danych wpisywanych do narzędzi AI. Gdy do przygotowania szablonu wiadomości nie są potrzebne prawdziwe nazwiska ani numery identyfikacyjne, można użyć danych przykładowych. Przed wklejeniem poufnego dokumentu do zewnętrznej usługi należy sprawdzić zasady jej używania obowiązujące w organizacji. Samo dopisanie do promptu „nie ujawniaj tych informacji” nie zastępuje kontroli dostępu.

Ważna jest też wiedza o tym, gdzie faktycznie znajdują się dane. W raporcie IBM dotyczącym naruszeń danych z 2024 r. 40% analizowanych incydentów obejmowało informacje przechowywane w różnych środowiskach, a 35% wiązało się z danymi w niezarządzanych źródłach. To statystyki dotyczące naruszeń ogółem, nie wyłącznie systemów AI. Pokazują jednak, dlaczego po incydencie nie wystarcza sprawdzenie jednego chatbota: trzeba znać również miejsca, z których pobiera on informacje i do których je przekazuje.

Przygotowany wcześniej sposób reagowania skraca czas potrzebny na pierwszą decyzję. Zespół powinien wiedzieć, kto może wyłączyć zagrożoną integrację, gdzie znajdują się ślady dostępu i kto ocenia skutki ujawnienia. Nie da to gwarancji odzyskania już skopiowanych danych, ale pozwoli szybciej zamknąć drogę ich dalszego wypływania.

Przeczytaj również:

Kategorie

Ostatnie posty

Do góry