Zatruwanie danych (data poisoning) - jak psuje się modele AI i bazy RAG

W skrócie: zatruwanie danych to atak na integralność. Atakujący nie łamie aplikacji ani nie zgaduje hasła - podsuwa systemowi materiał, z którego ten się uczy albo który cytuje jako źródło.

W firmie, która nie trenuje własnego modelu, realne wektory są trzy: baza wiedzy dla RAG, dostrajanie na własnych danych i gotowy model pobrany z publicznego repozytorium. Pierwszy z nich jest zwykłym problemem kontroli dostępu do zapisu, tylko w nowym przebraniu.

W ogólnym wpisie o testach aplikacji LLM zatruwanie danych pojawia się jako jedna z pozycji listy. Tutaj rozkładamy je osobno, bo to jedyna kategoria z tej listy, w której szkoda powstaje zanim ktokolwiek zada pytanie, i utrzymuje się po restarcie usługi.

Czym to się różni od wstrzykiwania promptu

Oba ataki polegają na tym, że model dostaje cudze polecenie. Różnica jest w trwałości i zasięgu.

	Wstrzykiwanie promptu	Zatruwanie danych
Gdzie siedzi	W treści rozmowy albo w dokumencie czytanym w trakcie jednej sesji.	W danych treningowych, w bazie wiedzy albo w wagach modelu.
Jak długo działa	Do końca kontekstu. Nowa sesja czyści sprawę.	Do czasu wykrycia i usunięcia źródła. Restart nic nie zmienia.
Kogo dotyczy	Zwykle jednego użytkownika i jednej rozmowy.	Każdego, kto zada pytanie trafiające w zatrute miejsce.
Jak się to wykrywa	Widać w logu rozmowy.	Trzeba porównać odpowiedź ze źródłem i sprawdzić, skąd to źródło się wzięło.

Granica bywa cienka: dokument z ukrytą instrukcją, który trafia do bazy wektorowej na stałe, jest jednocześnie pośrednim wstrzyknięciem promptu i zatruciem bazy wiedzy. W klasyfikacji OWASP odpowiadają za to dwie pozycje listy dla aplikacji LLM: LLM04 Data and Model Poisoning oraz LLM08 Vector and Embedding Weaknesses.

Cztery momenty, w których wchodzi trucizna

1. Trening modelu bazowego

Zbiory treningowe powstają w dużej części z automatycznego pobierania stron. To znaczy, że każdy, kto potrafi opublikować treść pod adresem, który trafi do zbioru, dorzuca swoją cegiełkę. Znane warianty to podmiana zawartości pod adresem już umieszczonym w zbiorze oraz wykupienie wygasłej domeny, która w tym zbiorze figuruje - od tego momentu wszystko, co pobiorą stamtąd kolejne procesy, pochodzi od nowego właściciela.

Dla większości firm to ryzyko odziedziczone, nie własne. Ale dziedziczy się je w całości razem z modelem.

2. Dostrajanie na własnych danych

Tutaj odpowiedzialność jest już Wasza. Materiał do dostrajania powstaje zwykle z tego, co firma ma pod ręką: zgłoszeń z helpdesku, korespondencji, treści z wewnętrznej wiki. Jeśli do któregokolwiek z tych źródeł może pisać osoba z zewnątrz - klient zakładający zgłoszenie, kontrahent w portalu, użytkownik formularza - to ta osoba współtworzy zbiór treningowy.

3. Baza wiedzy i embeddingi (RAG)

Najczęstszy realny przypadek w firmach i jednocześnie najmniej egzotyczny technicznie. Asystent odpowiada na podstawie dokumentów z SharePointa, Confluence albo dysku współdzielonego. Kto ma prawo zapisu do tego katalogu, ten ma wpływ na odpowiedzi asystenta dla całej organizacji.

Instrukcja nie musi być widoczna dla człowieka. Biały tekst na białym tle, treść w komentarzu, metadane pliku, zwinięta sekcja - dla czytnika, który wyciąga sam tekst, to wszystko jest zwykłą treścią dokumentu.

4. Pętla zwrotna

Systemy, które uczą się z własnej eksploatacji - zapisują preferencje użytkownika, budują pamięć długoterminową, zbierają oceny odpowiedzi, a potem wykorzystują to jako materiał do dalszego dostrajania - domykają obieg. Użytkownik, który dziś wpisuje coś do pamięci asystenta, jutro może to zobaczyć w odpowiedzi udzielonej komuś innemu.

Ile trzeba zatruć, żeby to zadziałało

Przez długi czas zakładano, że atakujący musi kontrolować jakiś procent zbioru treningowego, co przy dzisiejszych rozmiarach danych brzmi jak zabezpieczenie samo w sobie.

Badanie Anthropic, brytyjskiego AI Security Institute i Alan Turing Institute z 2025 roku podważa to założenie: backdoor udało się wszczepić stałą, niewielką liczbą dokumentów (rzędu 250), i to niezależnie od rozmiaru modelu. Model o 13 mld parametrów, trenowany na wielokrotnie większej ilości danych niż model 600-milionowy, uległ tej samej liczbie zatrutych próbek.

Zastrzeżenie

Badanie dotyczyło wąskiego backdoora (model na wyzwalacz generował bełkot) i modeli do 13 mld parametrów, więc nie jest dowodem, że dowolne zachowanie da się wszczepić tak samo tanio. Wniosek praktyczny jest jednak niezależny od tego zastrzeżenia: skala zbioru treningowego nie jest ochroną przed zatruciem.

Backdoor z wyzwalaczem

Najtrudniejszy do wykrycia wariant nie psuje modelu w sposób widoczny na co dzień. Model zachowuje się normalnie, dopóki w wejściu nie pojawi się konkretny ciąg: nazwa firmy, nietypowe słowo, sekwencja znaków, format daty.

Dlaczego zwykłe testy tego nie łapią: zestaw ewaluacyjny sprawdza jakość odpowiedzi na pytaniach, które ktoś wymyślił. Wyzwalacz jest z definicji czymś, czego nikt nie wymyślił. Dopóki go nie znasz, model przechodzi każdy test.

To samo dotyczy zatrutej bazy RAG. Zatruty dokument dotyczący jednej wąskiej procedury nie wypłynie, dopóki ktoś o tę procedurę nie zapyta.

Łańcuch dostaw modelu

Firma, która nic nie trenuje, ale pobiera gotowe wagi z publicznego repozytorium, przejmuje razem z nimi cały ich życiorys: dane treningowe, dostrojenia, adaptery. Model nie jest dokumentem, który da się przejrzeć - to kilka gigabajtów liczb, z których nie odczytacie, czego się nauczył.

Dochodzi do tego zwykłe ryzyko formatu: część formatów serializacji modeli wykonuje kod przy wczytywaniu. Załadowanie takiego pliku to nie odczyt danych, tylko uruchomienie cudzego kodu na Waszym serwerze. Ten wątek wpada już w klasyczny łańcuch dostaw oprogramowania i rządzi się tymi samymi zasadami: przypięte wersje, weryfikacja pochodzenia, formaty, które nie wykonują kodu.

Jak to sprawdzamy w teście

Mapa źródeł. Z czego dokładnie system korzysta przy odpowiadaniu i kto ma prawo zapisu do każdego z tych miejsc. To zwykle pierwsza niespodzianka - katalogi, o których nikt nie pamiętał, że są indeksowane.
Dokument znacznikowy. Wprowadzamy do bazy wiedzy dokument z unikalnym, nieszkodliwym znacznikiem i sprawdzamy, czy i w jakiej formie wypływa w odpowiedziach. To pokazuje realną drogę od zapisu do cytatu.
Treść jako polecenie. Czy zdanie zapisane w dokumencie potrafi zmienić zachowanie asystenta wobec innego użytkownika, czy jest traktowane wyłącznie jako materiał do zacytowania.
Izolacja między klientami i rolami. Czy filtrowanie po uprawnieniach odbywa się przed wyszukiwaniem w bazie wektorowej, czy dopiero na wynikach.
Pochodzenie modelu i adapterów. Skąd pochodzą wagi, czy wersje są przypięte, w jakim formacie są wczytywane.
Pętla zwrotna. Czy dane z eksploatacji wracają do dostrajania, a jeśli tak, to czy ktokolwiek je przed tym przegląda.

Co robić

Traktujcie zapis do bazy wiedzy jak zapis do produkcji. Jeśli asystent cytuje katalog, do którego pisze pół firmy i kilku kontrahentów, to jest to najsłabszy element systemu.
Oddzielcie źródła zaufane od reszty. Treści od klientów i z zewnątrz to materiał do przeczytania, nie do wykonania. Warto, żeby odpowiedź pokazywała, z którego dokumentu pochodzi.
Trzymajcie wersje i pochodzenie. Wiedzcie, która wersja bazy wiedzy i który model odpowiadały w danym dniu. Bez tego po wykryciu problemu nie da się ustalić zasięgu.
Zbudujcie zbiór regresyjny. Zestaw pytań z oczekiwanymi odpowiedziami, puszczany po każdej aktualizacji bazy albo modelu. Nie wykryje backdoora z nieznanym wyzwalaczem, ale wychwyci ciche przesunięcie odpowiedzi.
Przeglądajcie to, co wraca z eksploatacji. Dane z rozmów jako materiał treningowy wymagają tej samej kontroli co dane od zewnętrznego dostawcy.

Czego to nie załatwi

Żadna z powyższych praktyk nie daje pewności, że model bazowy jest czysty. Gwarancji nie ma nikt, łącznie z jego twórcą, i na dziś nie istnieje metoda przeszukania wag pod kątem nieznanego backdoora.

Dlatego sensowne założenie projektowe jest odwrotne: model może kłamać i może zostać zmanipulowany. Konsekwencje tego założenia dotyczą architektury, nie modelu - ograniczone uprawnienia narzędzi, potwierdzenie człowieka przed operacją nieodwracalną, kontrola po stronie serwera niezależna od tego, co model zaproponował.

Jeśli budujecie asystenta na własnych dokumentach albo agenta z dostępem do narzędzi, zobaczcie zakres testów penetracyjnych aplikacji LLM i to, jak przygotować firmę do testu.