Jak zabezpieczyć modele ML przed atakami typu data poisoning i adversarial examples

Dlaczego modele ML są podatne na data poisoning i adversarial examples

Bezpieczeństwo modeli ML a klasyczne bezpieczeństwo aplikacji

Modele ML są podatne na ataki, ponieważ ich zachowanie wynika głównie z danych, a nie z jawnie zapisanych reguł. W klasycznej aplikacji bezpieczeństwo to głównie kwestia kontroli dostępu, walidacji wejścia, uprawnień i poprawnego kodu. Jeśli programista nie doda konkretnej funkcji, aplikacja nie zacznie „magicznie” wykonywać nowych działań. W modelu ML granica jest znacznie mniej wyraźna – zmiana rozkładu danych może diametralnie zmienić decyzje modelu, bez modyfikacji jakiejkolwiek linijki kodu.

W systemach ML logika biznesowa jest rozproszona między kodem, zbiorem treningowym, funkcjami cech i parametrami modelu. Atakujący nie musi łamać hasła administratora, wystarczy, że wpłynie na dane: doda określony typ przykładów, zmanipuluje etykiety albo zacznie wysyłać odpowiednio spreparowane zapytania do API modelu. To właśnie ta zależność od danych powoduje, że klasyczne praktyki bezpieczeństwa są konieczne, ale nie wystarczające.

Dodatkowym utrudnieniem jest fakt, że modele często działają jak „czarne skrzynki”. Zespół produktowy widzi metryki (accuracy, AUC), ale nie rozumie, jak model dochodzi do konkretnych decyzji. To tworzy przestrzeń dla ataków, które nie są oczywiste na poziomie pojedynczych przykładów, ale kumulują się w skuteczne data poisoning lub wrażliwość na adversarial examples.

Jeśli proces bezpieczeństwa w organizacji kończy się na „szyfrujemy komunikację, mamy WAF przed API”, to jest to sygnał ostrzegawczy, że bezpieczeństwo modeli ML nie jest adresowane. W takiej sytuacji pipeline uczenia często pozostaje miękkim podbrzuszem całego systemu.

Źródła podatności: dane, brak deterministycznych reguł, złożone przestrzenie cech

Modele ML są trenowane na danych, które są jedynie przybliżeniem rzeczywistego świata. Każdy błąd, uprzedzenie czy manipulacja w tym zbiorze może zostać „wzmocniona” przez proces uczenia. Główne źródła podatności to:

• Zależność od danych: mała liczba przykładów dla ważnych klas, zbyt silna dominacja jednego źródła, brak kontroli nad tym, co trafia do zbioru treningowego.
• Brak deterministycznych reguł: nie ma prostego „if-else”, który można zrewidować. Model aproksymuje złożoną funkcję na podstawie punktów danych – drobne lokalne manipulacje mogą przynieść globalne zmiany.
• Złożone, wysokowymiarowe przestrzenie cech: w wielu wymiarach zawsze da się znaleźć kierunek, w którym mała perturbacja robi dużą różnicę dla modelu, a pozostaje „niewidoczna” dla człowieka (klucz do adversarial examples).

Wysokowymiarowość to szczególny problem w sieciach neuronowych do CV i NLP. Normalne dane tworzą cienką „manifold” w przestrzeni pikseli czy tokenów. Adversarial examples przesuwają punkt minimalnie poza tę manifold, ale w kierunku, w którym model ma duże nachylenie funkcji decyzyjnej. Dla człowieka różnica jest zerowa lub minimalna, dla modelu – krytyczna.

Jeżeli zespół ML nie potrafi wskazać, w jakich podprzestrzeniach cech model jest najbardziej wrażliwy (np. okolice granic decyzyjnych, rzadkie klasy, nietypowe kombinacje cech), trudno będzie zbudować odporność na data poisoning i adversarial examples. To kolejny punkt kontrolny w audycie bezpieczeństwa ML.

Trening vs predykcja: dwa różne wektory ataku

Ataki na systemy ML dzielą się na dwie główne kategorie:

• Ataki na dane treningowe (data poisoning): celem jest zmiana parametrów modelu poprzez manipulację zbiorem treningowym. Przykłady: podmiana etykiet (label flipping), dodanie próbek z „ukrytym” sygnałem (backdoor), masowe zgłoszenia od użytkowników, które „przekalibrują” model.
• Ataki na dane wejściowe w trakcie predykcji (adversarial examples): celem jest wymuszenie błędnej predykcji przy minimalnej zmianie wejścia. Przykłady: delikatne perturbacje obrazu, dopisanie kilku słów do tekstu, mikro-zmiany cech liczbowych w wniosku kredytowym.

Data poisoning jest często atakem długoterminowym – efekty pojawiają się dopiero po kolejnym retreningu modelu. Adversarial examples działają natychmiast, w momencie wywołania API modelu. Z punktu widzenia MLOps oznacza to potrzebę dwóch odrębnych linii obrony: jedna chroni pipeline danych, druga – warstwę inference.

Jeśli organizacja ma proces retrainingu typu „weź wszystkie najnowsze dane z produkcji, doklej do starego datasetu, wytrenuj, wdroż”, bez kontroli źródeł i bez analizy trendów, to jest to silny sygnał ostrzegawczy podatności na data poisoning. Z kolei brak kontroli nad tym, kto i jak często wywołuje API modelu, to otwarte zaproszenie do eksploracji adversarial i model extraction.

Scenariusze biznesowe o podwyższonym ryzyku ataku

Nie każdy model jest równie atrakcyjny dla napastnika. Najbardziej narażone są systemy, których decyzje mają bezpośrednią wartość finansową lub regulacyjną. Typowe scenariusze wysokiego ryzyka:

• Fraud detection i scoring ryzyka: atakujący ma silną motywację, aby zrozumieć granice decyzyjne i znaleźć kombinacje cech, które „przechodzą”. Data poisoning może polegać na zgłaszaniu transakcji jako „prawidłowe”, mimo że są na granicy oszustwa.
• Moderacja treści: użytkownicy mogą masowo oznaczać określone treści jako „niepożądane” lub odwrotnie, aby przesunąć próg czułości modelu. Możliwe są też adversarial examples w postaci zmodyfikowanych obrazów lub tekstów tak, by omijały filtry.
• Systemy rekomendacyjne: sprzedawcy lub twórcy treści mogą próbować manipulować rankingiem poprzez sztuczne interakcje, recenzje lub kliki. To połączenie klasycznego „gaming the system” z data poisoning.
• Biometria i rozpoznawanie obrazu: systemy kontroli dostępu, rozpoznawania twarzy czy tablic rejestracyjnych są celem dla ataków adversarial (np. specjalne okulary, naklejki na znakach, modyfikacje obrazu).

Jeśli model wpływa na pieniądze, dostęp lub reputację, model zagrożeń musi explicite uwzględniać aktywnego przeciwnika. Brak takiego ujęcia to sygnał, że bezpieczeństwo ML jest traktowane jak problem wyłącznie techniczny, a nie strategiczny.

Jak rozpoznać, że organizacja ignoruje bezpieczeństwo ML

Podczas audytu bezpieczeństwa modeli ML kilka elementów pojawia się jako powtarzalne sygnały ostrzegawcze. Kluczowe z nich:

• Brak formalnego właściciela danych dla głównych zbiorów treningowych.
• Brak logów zmian datasetu: nie wiadomo, kto, kiedy i dlaczego zmienił dane.
• Automatyczny retraining oparty na „wszystkich nowych danych z produkcji”, bez filtracji i segmentacji źródeł.
• Brak procesów przeglądu anomalii w danych (nikt nie patrzy, co zmieniło się między wersjami datasetu).
• Brak polityki kontroli dostępu do API modelu oraz brak limitów zapytań.

Jeśli choć dwa z tych punktów są prawdziwe dla krytycznego modelu, to bezpieczeństwo ML jest najprawdopodobniej na poziomie „nadziei i zaufania”, a nie powtarzalnego procesu. W takiej sytuacji nawet najlepsze techniki robust training nie zrekompensują chaosu na poziomie danych.

Kluczowe pojęcia: data poisoning, adversarial examples, threat model

Data poisoning: manipulacja danymi treningowymi

Data poisoning to celowa manipulacja danymi treningowymi w taki sposób, aby zmienić zachowanie modelu po ponownym trenowaniu. Atakujący może mieć trzy główne cele:

• Integrity: wymuszenie błędnych predykcji dla konkretnych przypadków (np. określony typ transakcji zawsze klasyfikowany jako „bezpieczny”).
• Availability: ogólne pogorszenie jakości modelu, np. aby system stał się bezużyteczny, a organizacja wróciła do ręcznej obsługi.
• Privacy: w niektórych scenariuszach data poisoning może być użyty do wstrzyknięcia danych, które później umożliwiają odtworzenie elementów zbioru treningowego (rzadziej, ale istnieje).

W praktyce data poisoning często przyjmuje formę masowego dostarczania przykładów z określonym wzorcem etykiet lub cech. Dla zespołu ML mogą to być „normalne” dane użytkowników, dla atakującego – precyzyjnie zaprojektowana sekwencja, która przesuwa granice decyzyjne.

Jeśli proces MLOps pozwala zewnętrznym użytkownikom na nielimitowany wkład do zbioru treningowego (np. zgłoszenia w systemie moderacji, oceny produktów) bez segmentacji i bez wag, to data poisoning jest tylko kwestią czasu, a nie hipotetycznym ryzykiem.

Adversarial examples: małe perturbacje, duże skutki

Adversarial examples to dane wejściowe celowo zmodyfikowane w minimalny sposób tak, aby spowodować błędną predykcję modelu, przy zachowaniu niemal identycznego wyglądu lub znaczenia z perspektywy człowieka. Kluczowe cechy:

• Minimalna zmiana w przestrzeni wejścia: np. niewielka zmiana pikseli w obrazie lub dodanie niemal neutralnego słowa w tekście.
• Maksymalny efekt na wyjściu modelu: zmiana klasy, obniżenie pewności, przejście przez próg decyzji.
• Ukierunkowanie na konkretny model: perturbacja jest zwykle wyliczana z użyciem gradientów lub przybliżeń gradientów danego modelu lub modelu zastępczego.

W przeciwieństwie do data poisoning, adversarial examples nie zmieniają parametrów modelu, lecz wykorzystują jego istniejącą wrażliwość. Atakujący może iteracyjnie sondować model, generować perturbacje (np. metodami FGSM, PGD) i z czasem uzyskać zestaw wejść, które masowo wprowadzają model w błąd.

Jeśli system ML przyjmuje dane wejściowe bez jakiejkolwiek walidacji, bez detekcji anomalii i bez redundancji (np. brak drugiego, prostszego modelu jako sanity check), to adversarial examples mają otwartą drogę do produkcji.

Threat model: co wie napastnik i do czego ma dostęp

Skuteczne zabezpieczenie modeli ML wymaga formalnego threat modelu – opisu tego, kogo się obawiamy i jaki ma budżet ataku. Bez tego organizacja albo przepłaca za zbyt zaawansowane zabezpieczenia, albo odkłada w czasie krytyczne działania.

Podstawowe wymiary threat modelu dla systemów ML:

• Poziom wiedzy o modelu:
  • White-box – napastnik zna architekturę, parametry, loss, ma dostęp do gradientów.
  • Black-box – napastnik może zadawać pytania do API i obserwuje odpowiedzi (czasem z confidence scores), ale nie zna wnętrza.
  • Gray-box – częściowa wiedza, np. architektura znana, ale parametry nie, lub odwrotnie.
• Zakres dostępu: dostęp do danych treningowych, możliwość wstrzykiwania nowych przykładów, dostęp do pipeline ETL, możliwość masowego wywoływania API inference.
• Motywacja i budżet ataku: jednorazowy zysk vs długoterminowa korzyść, dostęp do mocy obliczeniowej (GPU), zdolność do rewersu modelu.

Threat model powinien być udokumentowany, a nie domyślany. To krytyczny punkt kontrolny: jeśli zespół nie potrafi w jednym akapicie opisać, jakiego typu przeciwnika zakłada dla danego modelu, nie ma mowy o sensownym projektowaniu obrony przed data poisoning i adversarial examples.

Przykłady prostych ataków: label flipping, backdoor, gradient-based

Najczęściej spotykane typy ataków w praktyce:

• Label flipping: atakujący wprowadza do zbioru treningowego próbki z prawidłowymi cechami, ale z błędnymi etykietami. W fraud detection może to być oznaczanie podejrzanych transakcji jako „OK”. Jeśli takich próbek jest wystarczająco dużo, model zaczyna przesuwać granice decyzyjne.
• Backdoor poisoning: atakujący wprowadza do danych treningowych przykłady z określonym wzorcem (trigger), np. mały znak w rogu obrazu, który zawsze jest etykietowany jako „klasa A”. Po treningu model nauczy się, że ten wzorzec jest silnym sygnałem dla klasy A. W produkcji atakujący dołącza trigger do dowolnego obrazu, aby wymusić klasyfikację na klasę A.
• Gradient-based adversarial attacks: w white-box atakujący oblicza gradient loss po wejściu i modyfikuje dane w kierunku maksymalizującym błąd. FGSM (Fast Gradient Sign Method) i PGD (Projected Gradient Descent) są najpopularniejszymi koncepcjami, choć w praktyce istnieje wiele wariantów.

Każdy z tych ataków ma inne objawy w danych i metrykach. Label flipping może powodować wzrost entropii predykcji na zbiorze treningowym. Backdoor często nie wpływa znacząco na globalne metryki, ale tworzy „tajne przejście” dla konkretnych wzorców. Gradient-based adversarial examples ujawniają się przy nieoczekiwanych błędach na przykładach, które dla człowieka wyglądają zupełnie poprawnie.

Rodzaje ataków typu data poisoning – jak wyglądają w realnych pipeline’ach

Poisoning poprzez kanały feedbacku użytkowników

Najbardziej oczywisty wektor to wszystkie miejsca, gdzie użytkownik „uczy” system: zgłoszenia, feedback, oceny, raporty błędów. Jeśli te dane trafiają później (w całości lub w dużej części) do retrainingu, stają się naturalnym polem do data poisoning.

• Systemy moderacji treści: zgłoszenia „to jest spam”, „to jest OK”, odwołania od decyzji. Atakujący może masowo zgłaszać legalne treści jako naruszenia albo odwrotnie – promować szkodliwe treści jako poprawne.
• Fraud / risk scoring: reklamacje klientów, samodzielne oznaczenia transakcji jako „niesłusznie zablokowana”, „fałszywy alarm”. Zorganizowana grupa może tworzyć pozornie wiarygodne odwołania, które po włączeniu do treningu rozmiękczają granicę między fraudem a zachowaniem normalnym.
• Rekomendacje i ranking: oceny produktów, „lajki”, „dislajki”, zgłoszenia niskiej jakości wyników wyszukiwania. Przez dłuższy czas model może być karmiony zmanipulowanym obrazem preferencji.

Punkt kontrolny: każdy kanał feedbacku użytkownika, który choćby częściowo trafia do zbioru treningowego, musi mieć osobne reguły filtracji i wag. Jeśli feedback jest traktowany tak samo jak dane „nieinteraktywne”, to jest to bezpośredni sygnał ostrzegawczy.

Poisoning przez logi produkcyjne i automatyczny retraining

Automatyczny retraining na bazie logów z produkcji (clickstream, request/response, eventy) jest wygodny, ale tworzy zamkniętą pętlę: model wpływa na dane, które go uczą. Atakujący może to wykorzystać.

• Feedback loop w wyszukiwaniu: jeśli model rankingu promuje konkretne wyniki, to zbiera więcej klików właśnie na nich. To normalne zjawisko, ale atakujący może wzmocnić efekt, generując sztuczne kliki w preferowane wyniki. Dane treningowe stają się stopniowo „zainfekowane” jednym wzorcem zachowań.
• API scoringowe: jeśli model finansowy klasyfikuje wnioski kredytowe, to logi odrzuconych wniosków mogą być mniej wiarygodne (ludzie nie kończą procesu, zmieniają dane). Atakujący może wielokrotnie składać wnioski z nieznacznie zmienionymi parametrami, budując w logach fałszywy obraz „normalności”.
• Systemy detekcji anomalii: gdy wynik modelu jest elementem logów, które później służą do treningu kolejnych wersji, pojawia się ryzyko „przyzwyczajenia” modelu do anomalii, jeśli są one długotrwale obecne i nie są korygowane.

Jeśli retraining odbywa się „na autopilocie”, bez przeglądu zmian rozkładu danych i bez porównywania kluczowych statystyk między wersjami, to niewielki początkowo poisoning może niezauważalnie przerodzić się w trwałą zmianę zachowania modelu.

Poisoning w procesach ETL i łączeniu źródeł danych

Wiele skutecznych ataków nie odbywa się na poziomie pojedynczych przykładów, tylko na poziomie pipeline’u. Celem jest wstrzyknięcie danych „u źródła” lub na granicy między systemami.

• Fałszywe źródła „zewnętrzne”: np. crawlowanie internetu, zasilanie z otwartych API, dane OSINT. Atakujący może przygotować strony, które wyglądają jak normalne źródła, a w istocie zawierają precyzyjnie przygotowane przykłady (teksty, obrazy, recenzje).
• Manipulacja joinów i mapowań: jeśli pipeline łączy dane z wielu tabel / systemów po słabych kluczach (np. email, cookie, fingerprint), atakujący może doprowadzić do „zlepienia” profili kilku osób. Powstały rekord uczy model błędnych korelacji.
• Wstrzykiwanie przez narzędzia BI / analityczne: raporty analityczne czasem są źródłem dodatkowych cech (feature’ów). Jeśli istnieje możliwość eksportu danych z zewnętrznego narzędzia do feature store bez walidacji, to jest to brama dla poisoning.

Krytyczne minimum to jawna mapa źródeł danych z oznaczeniem poziomu zaufania. Jeśli zespół nie potrafi odpowiedzieć, które źródła są uznawane za „wysokiego ryzyka” i jak są odseparowane, to pipeline jest de facto „otwartym systemem przyjmującym cokolwiek”.

Poisoning specyficzny dla modeli foundation i LLM

W przypadku dużych modeli językowych i multimodalnych data poisoning przyjmuje inne formy, ale mechanika jest podobna: zmiana rozkładu danych tak, żeby przesunąć zachowanie modelu.

• Poisoning korpusu publicznego: publikowanie treści z określonym słownictwem, wzorcem odpowiedzi, błędnymi faktami – w miejscach chętnie pobieranych przez dostawców datasetów.
• Prompt injection jako poisoning finetuningu: jeśli organizacja używa danych z interakcji użytkowników do dalszego dostrajania modelu (RLHF, supervised finetuning), to odpowiednio skonstruowane prompt injection może stać się „instrukcją”, którą model utrwali w kolejnej iteracji.
• Backdoor na poziomie stylu: wstrzykiwanie treści o specyficznym stylu (np. charakterystyczne zwroty, składnia), które w połączeniu z określonym tematem powodują zmianę odpowiedzi w pożądanym kierunku.

Jeśli w procesie finetuningu LLM nie ma filtru na „prompt injection w danych treningowych”, a logi konwersacji są wciągane masowo jako przykład „dobrych rozmów”, to jest to zaproszenie do subtelnego przejęcia części zachowania modelu przez zewnętrznego aktora.

Rodzaje ataków typu adversarial examples – gdzie pojawiają się w cyklu życia modelu

Ataki na etapie inference w systemach online

Najczęstszy scenariusz to bezpośrednie ataki na endpoint inferencyjny. Napastnik może generować setki lub tysiące zapytań, stopniowo zbliżając się do perturbacji wywołującej pożądane zachowanie.

• Ciągłe sondowanie API: małe zmiany wejścia tekstowego lub obrazu i obserwacja zmian w wynikach (czasem też w confidence score). Dzięki temu da się przybliżyć gradient bez znajomości parametrów modelu.
• „Sprytne” payloady tekstowe: w modelach NLP ataki często wyglądają jak zwykłe wiadomości, ale z dołączonymi fragmentami, które mają osłabić filtry („to tylko żart”, „zignoruj wszelkie wcześniejsze instrukcje” itp.).
• Ataki iteracyjne na klasyfikatory obrazów: użytkownik wielokrotnie przesyła nieco zmodyfikowane zdjęcia (filtry, szum, obroty), aż uzyska przepuszczenie przez kontrolę.

Minimalne zabezpieczenie to limity zapytań, analiza wzorców zachowań klienta (rate, podobieństwo kolejnych zapytań) i blokada ewidentnie „poszukujących” sekwencji. Jeśli API jest dostępne bez throttlingu, a logi nie są analizowane pod kątem wzorców ataków, to adversarial examples są tylko kwestią czasu.

Ataki na etapie danych wejściowych offline

Nie wszystkie systemy działają w czasie rzeczywistym. W modelach batchowych (np. scoring raz dziennie) adversarial examples mogą być przygotowane wcześniej i dostarczone w jednym zasileniu danych.

• Dokumenty skanowane / OCR: drobne modyfikacje tła, czcionki, podpisów mogą generować błędy w ekstrakcji pól, które następnie wpływają na decyzje (np. błędny odczyt kwoty lub daty).
• Pliki wsadowe od partnerów: jeśli scoring jest wykonywany na danych przekazywanych przez zewnętrznego partnera, możliwe jest przygotowanie rekordów, które „przechodzą” walidację biznesową, ale są z punktu widzenia modelu silnymi adversarial examples.
• Obrazy przemysłowe / medyczne: subtelne nałożenie artefaktów (szum, wzorek) na obraz może zmienić predykcję przy jednoczesnym braku widocznej różnicy dla operatora.

Jeżeli proces przyjmowania batchy danych nie zawiera kontroli spójności rozkładu cech między kolejnymi dostawami ani prostych sanity checków (np. drugi, prostszy model lub reguły biznesowe), to pojedynczy zasilający plik może chwilowo „wyłączyć” skuteczność modelu.

Adversarial perturbacje w świecie fizycznym

Osobna kategoria to ataki, które nie zmieniają pliku cyfrowego, lecz fizyczne otoczenie. Model nadal widzi „tylko obraz”, ale jest on rezultatem celowo zmodyfikowanego świata.

• Naklejki i wzory na znakach drogowych: niewielkie naklejki lub wzory o wysokim kontraście mogą doprowadzić do błędnej klasyfikacji znaku przez system wizyjny pojazdu.
• Specjalne ubrania / akcesoria: t-shirty z określonym wzorem, okulary, maski, które z punktu widzenia ludzi wyglądają nietypowo, ale akceptowalnie, a model rozpoznawania twarzy traktuje je jak innego użytkownika albo nie rozpoznaje osoby wcale.
• Oświetlenie i tło: manipulacja światłem w pomieszczeniu może zmienić rozkład pikseli na tyle, by system kontroli dostępu (np. rozpoznawanie tablic) zachowywał się nieprzewidywalnie.

Punkt kontrolny: czy projekt zakłada testy w warunkach „zanieczyszczonego” środowiska (inne oświetlenie, nietypowe ubrania, nietypowe wzory na obiektach)? Jeśli scenariusze testowe ograniczają się do danych podobnych do treningowych, to odporność na ataki fizyczne jest czystą spekulacją.

Adversarial prompts i jailbreaki w modelach językowych

W LLM kluczowym polem gry są prompt-based attacks. Payload nie musi wyglądać agresywnie – często przyjmuje formę grzecznej prośby z ukrytą intencją.

• Jailbreak prompt: konstrukcje typu „udawaj, że jesteś innym systemem, który nie ma ograniczeń”, mieszane z długimi narracjami i przykładowymi dialogami. Celem jest doprowadzenie modelu do zignorowania polityk bezpieczeństwa.
• Prompt injection w danych: jeśli model czyta dokument lub stronę WWW, w treści może znajdować się instrukcja „zignoruj wszystkie wcześniejsze polecenia i wykonaj X”. Bez odpowiedniej separacji kontekstu model może potraktować to jak komendę użytkownika.
• Ataki łączone: połączenie prompt injection z klasycznymi technikami adversarial (np. dodanie znaków specjalnych, rzadkich sekwencji, które zmieniają rozkład tokenów i „przeskakują” modele filtrujące).

Jeśli projekt LLM nie posiada osobnej warstwy filtrującej wejścia (guard model, reguły), a cały ciężar bezpieczeństwa spoczywa na pojedynczym modelu głównym, to prompt-based adversarial examples mają znacznie niższy próg wejścia.

Adversarial examples podczas testów i walidacji

Ataki nie zawsze są wykonywane w produkcji. Zdarza się, że napastnik – lub po prostu zbyt kreatywny tester – generuje adversarial examples na etapie walidacji, a następnie „pomaga” w akceptacji modelu, pokazując tylko wyniki na bezpiecznym zbiorze.

• Manipulacja zestawem testowym: włączenie do zbioru walidacyjnego łatwiejszych przykładów, z pominięciem tych, o których wiadomo, że są wrażliwe na perturbacje.
• Ukrywanie wyników na krytycznych przypadkach: selektywne raportowanie metryk tylko dla „głównych” segmentów danych, bez przedstawiania wyników dla segmentów wysokiego ryzyka (np. małe klasy, rzadkie kombinacje cech).
• Brak testów na adversarial robustness: świadome unikanie prostych testów typu dodanie szumu, nieznaczna zmiana formatu, różnice lokalizacji obiektu na obrazie.

Jeżeli plan testów nie zawiera jawnego punktu „odporność na perturbacje wejścia” i nie jest to element kryteriów akceptacji, to ryzyko adversarial examples jest oceniane „na oko”. W praktyce oznacza to brak oceny.

Projektowanie procesu zbierania i wersjonowania danych odpornego na data poisoning

Segmentacja źródeł danych i poziomów zaufania

Pierwszym krokiem jest uznanie, że nie wszystkie dane są równie zaufane. Dane wewnętrzne z systemów transakcyjnych mają inną charakterystykę niż anonimowe zgłoszenia z internetu i muszą być inaczej traktowane.

• Klasy zaufania dla źródeł: np. „wysokie zaufanie” (systemy core, logi transakcyjne), „średnie” (partnerzy z umową), „niskie” (użytkownicy anonimowi, web scraping).
• Oddzielne pipeline’y: różne ścieżki ETL dla poszczególnych poziomów zaufania, z różnymi progami walidacji, monitoringiem i wagami w treningu.
• Minimalne uprawnienia: ograniczenie komu i z czego wolno tworzyć zbiory treningowe; dane „niskiego zaufania” nie powinny być domyślnie łączone z „wysokim” bez explicite review.

Jeśli w repozytorium danych „wszystko jest równe” i nie ma oznaczeń źródła oraz poziomu zaufania, to każdy nowy dataset może być mieszanką danych dobrej i złej jakości, bez świadomości ryzyka poisoning.

Wersjonowanie datasetów jako centralny punkt kontrolny

Wersjonowanie datasetów nie jest fanaberią, tylko mechanizmem audytowalności. Pozwala odpowiedzieć na pytanie: co dokładnie się zmieniło między wersją modelu, która działała dobrze, a obecną.

Najważniejsze wnioski

• Modele ML są podatne na ataki, ponieważ ich zachowanie jest kształtowane głównie przez dane, a nie przez twardo zapisane reguły; jeśli bezpieczeństwo kończy się na WAF i szyfrowaniu, to sygnał ostrzegawczy, że pipeline danych jest niechronionym elementem systemu.
• Logika biznesowa w systemach ML jest rozproszona między kod, dane, cechy i parametry, więc atakujący nie musi łamać uprawnień – wystarczy, że wpłynie na zbiór treningowy lub ruch do API; minimum to traktowanie danych treningowych jak krytycznego zasobu infrastruktury.
• Kluczowe źródła podatności to zależność od jakości i rozkładu danych, brak deterministycznych reguł, które można zrewidować, oraz wysokowymiarowe przestrzenie cech, w których niewielka perturbacja może drastycznie zmienić decyzję modelu, pozostając praktycznie niewidoczna dla człowieka.
• Brak wiedzy, gdzie znajdują się wrażliwe podprzestrzenie cech (granice decyzyjne, rzadkie klasy, nietypowe kombinacje) to istotny punkt kontrolny w audycie – jeśli zespół nie potrafi ich wskazać ani monitorować, trudno będzie wykryć ani przewidzieć skuteczne ataki.
• Istnieją dwa główne wektory ataku: data poisoning (manipulacja danymi treningowymi, działanie odsunięte w czasie) i adversarial examples (atak na dane wejściowe w trakcie predykcji, skutek natychmiastowy); obrona musi mieć dwie warstwy: dla pipeline’u uczenia i dla warstwy inference.