Data poisoning: jak zatruwa się dane, którymi uczy się i karmi AI

Większość rozmów o bezpieczeństwie AI dotyczy tego, co dzieje się na wejściu działającego modelu — prompt injection, jailbreaki, nadużycia. Znacznie mniej mówi się o groźniejszym, bo cichszym problemie: co, jeśli sam model jest skażony od środka, bo zatruto dane, na których się uczył lub które pobiera? To jest data poisoning — atak na integralność AI. Nie kradnie danych i nie wywołuje awarii; sprawia, że model po cichu robi to, co chce napastnik, a Ty nawet nie wiesz, że coś jest nie tak. Przyjrzyjmy się, jak to działa i dlaczego jest tak podstępne.

Zasada: model jest tak dobry, jak jego dane

Model uczenia maszynowego nie „rozumie” świata — wyciąga wzorce z danych, które mu podano. Jeśli te dane są rzetelne, model bywa użyteczny. Jeśli są skażone, model uczy się skażonych wzorców — i powiela je z pełnym przekonaniem. Data poisoning to celowe wprowadzenie do danych treści, które zmieniają zachowanie modelu w sposób korzystny dla napastnika. Kluczowa cecha, która czyni ten atak groźnym: jest niemal niewidoczny. Model działa „normalnie”, przechodzi testy, a złośliwe zachowanie ujawnia się tylko w konkretnych, znanych napastnikowi warunkach.

Zatrucie może uderzyć w trzech miejscach cyklu życia AI. Omówmy każde.

1. Zatrucie danych treningowych

Duże modele uczą się na gigantycznych zbiorach zgarnianych z internetu. I tu pojawia się problem: skoro dane pochodzą z publicznej sieci, napastnik też może do niej pisać. Badania pokazały dwie praktyczne ścieżki zatrucia zbiorów budowanych z web-scrapingu:

• Zatrucie przez wygaśnięte domeny i edytowalne źródła. Część zbiorów treningowych wskazuje na konkretne adresy URL. Jeśli domena wygaśnie albo źródło jest edytowalne (jak otwarte encyklopedie), napastnik może wykupić/zmodyfikować zawartość, którą później pobierze crawler — i wstrzyknąć swoje treści do korpusu.
• Zatrucie „na czas migawki”. Zbiory bywają tworzone przez zrzut zawartości w znanym momencie. Napastnik, który wie, kiedy to nastąpi, może chwilowo podmienić treść dokładnie na czas pobrania.

Co ważne, badania wskazują, że nie trzeba zatruć dużej części danych — czasem ułamek procenta wystarczy, by wszczepić modelowi konkretne, ukryte zachowanie. To zmienia rachunek ryzyka: atak jest tańszy, niż się wydaje.

2. Zatrucie fine-tuningu

Wiele firm nie trenuje modeli od zera — dostosowuje gotowe modele (fine-tuning) na własnych, mniejszych zbiorach. To skraca dystans między napastnikiem a modelem: jeśli dane do fine-tuningu pochodzą z niepewnego źródła (kupiony zbiór, dane od zewnętrznego dostawcy, treści od użytkowników), łatwiej je skazić. Zatruty fine-tuning może wszczepić backdoora: model zachowuje się poprawnie, dopóki nie zobaczy sekretnego „wyzwalacza” (określonego słowa, frazy, wzorca), po którym zmienia działanie — np. omija reguły bezpieczeństwa albo zwraca spreparowaną odpowiedź.

3. Zatrucie indeksu RAG (retrieval poisoning)

To najbliższy większości firm scenariusz, bo dotyczy popularnej architektury RAG (retrieval-augmented generation), w której model odpowiada na podstawie firmowych dokumentów pobieranych z bazy wiedzy. Jeśli napastnik zdoła umieścić w tej bazie spreparowany dokument, to gdy model go pobierze, potraktuje jego treść jako wiarygodne źródło — i na jego podstawie udzieli użytkownikowi zmanipulowanej odpowiedzi (fałszywej procedury, złego numeru konta, szkodliwej rekomendacji). To zatrucie łączy się z prompt injection: wstrzyknięty dokument może zawierać zarówno dezinformację, jak i ukryte polecenia.

Dlaczego to takie podstępne

Data poisoning różni się od większości ataków jednym: nie widać go. Wyciek danych zostawia ślad, ransomware szyfruje pliki, awaria jest oczywista. Zatruty model przechodzi standardowe testy i pracuje jak należy — dopóki nie zostanie spełniony warunek znany tylko napastnikowi. To sprawia, że atak jest trudny do wykrycia po fakcie i szczególnie niebezpieczny w zastosowaniach o wysokiej stawce (medycyna, finanse, bezpieczeństwo), gdzie zmanipulowana odpowiedź może mieć poważne skutki.

To także odrębny problem od zatruwania pamięci agentów AI: tam celem jest pamięć długotrwała działającego agenta, tu — dane, na których model się uczy lub które pobiera. Warto rozumieć oba, bo bronią się inaczej.

Jak bronić integralności danych AI

Skoro atak dotyczy danych, obrona też zaczyna się od danych — od ich pochodzenia i kontroli:

• Proweniencja i kuracja danych. Wiedz, skąd pochodzą Twoje dane treningowe i do fine-tuningu. Preferuj źródła zaufane i wersjonowane; unikaj ślepego zaufania anonimowym, publicznym zbiorom. To odpowiednik zasady „znaj swoje zależności” z bezpieczeństwa łańcucha dostaw oprogramowania.
• Integralność i podpisywanie. Traktuj zbiory danych i modele jak artefakty łańcucha dostaw: weryfikuj sumy kontrolne, podpisuj i sprawdzaj proweniencję. To ta sama logika, co przy Sigstore i SLSA — pochodzenie musi być weryfikowalne.
• Kontrola dostępu do bazy wiedzy (RAG). Ogranicz, kto i co może dodać do indeksu, z którego korzysta model. Baza wiedzy zasilana bez kontroli to otwarte zaproszenie do retrieval poisoning.
• Detekcja anomalii w danych. Nietypowe, odstające próbki w zbiorze treningowym bywają sygnałem zatrucia — warto je wyłapywać przed treningiem.
• Ewaluacja i red teaming zachowań. Testuj model nie tylko pod kątem jakości, ale i ukrytych zachowań: szukaj backdoorów, sprawdzaj reakcje na nietypowe wyzwalacze, oceniaj odporność. Zdolność powiedzenia „coś jest nie tak z tym modelem” wymaga celowego testowania.
• Ostrożność z modelami z niepewnych źródeł. Model pobrany z publicznego repozytorium może zawierać wszczepione zachowania niewidoczne w standardowych testach — a pliki modeli bywają też nośnikiem klasycznego złośliwego kodu (niebezpieczna deserializacja). Uruchamiaj je w izolacji i traktuj jak niezaufany komponent.

Podsumowanie

Data poisoning to atak na fundament AI — na dane, z których model wyciąga wzorce. Może uderzyć w zbiór treningowy (nawet ułamek procenta skażenia bywa skuteczny), w fine-tuning (wszczepiając backdoora) albo w indeks RAG (podsuwając modelowi zmanipulowane „źródło prawdy”). Jest groźny właśnie dlatego, że niewidoczny: model działa normalnie, dopóki nie padnie sekretny wyzwalacz. Obrona sprowadza się do integralności danych — znajomości ich pochodzenia, kontroli dostępu do baz wiedzy, weryfikacji proweniencji modeli i celowego testowania ukrytych zachowań. W świecie AI stare hasło brzmi teraz inaczej: nie „śmieci na wejściu, śmieci na wyjściu”, lecz „trucizna na wejściu, broń na wyjściu”.

Budujecie system oparty na własnych danych (fine-tuning, RAG) i chcecie ocenić jego odporność na zatrucie oraz integralność łańcucha danych? Porozmawiajmy — audyt i testy bezpieczeństwa rozwiązań AI obejmują ten obszar.

Najczęstsze pytania (FAQ)

Czym data poisoning różni się od prompt injection? Prompt injection działa na wejściu gotowego modelu — złośliwa treść zmienia jego zachowanie w danej sesji. Data poisoning działa wcześniej: skaża dane, na których model się uczy lub które pobiera, wszczepiając zachowanie „na stałe”. Prompt injection jest ulotny i dotyczy sesji; poisoning jest trwały i dotyczy samego modelu lub jego bazy wiedzy.

Czy trzeba zatruć dużo danych, żeby atak zadziałał? Nie zawsze. Badania pokazują, że w niektórych scenariuszach wystarczy skazić bardzo mały ułamek zbioru, by wszczepić modelowi konkretne, ukryte zachowanie wyzwalane sekretną frazą. To sprawia, że atak jest tańszy i bardziej realny, niż podpowiada intuicja — a jednocześnie trudniejszy do wykrycia.

Korzystamy tylko z gotowego modelu przez API i RAG — czy nas to dotyczy? Tak, przez indeks RAG. Jeśli baza wiedzy, z której model pobiera dokumenty, przyjmuje treści bez kontroli, napastnik może umieścić w niej spreparowany dokument i wpłynąć na odpowiedzi. Nie trenujecie modelu, ale integralność Waszej bazy wiedzy jest równie ważna — to najczęstszy wektor zatrucia dla firm.

Jak wykryć, że model został zatruty? To trudne, bo zatruty model działa normalnie do momentu wyzwolenia. Pomaga celowa ewaluacja i red teaming (szukanie ukrytych zachowań i reakcji na nietypowe wzorce), kontrola proweniencji danych i modeli, detekcja anomalii w zbiorach treningowych oraz traktowanie modeli z niepewnych źródeł jak niezaufanych komponentów uruchamianych w izolacji.