Kradzież modeli AI: extraction i wycieki danych

Kradzież modelu AI nie musi oznaczać włamania do repozytorium i pobrania pliku z wagami. Publiczne lub partnerskie API może ujawniać wystarczająco dużo informacji, aby atakujący wytrenował model zastępczy na odpowiedziach celu. Inne ataki próbują ustalić, czy konkretny rekord należał do zbioru treningowego, odtworzyć cechy danych albo wydobyć zapamiętane fragmenty.

Najkrótsza odpowiedź: model extraction, membership inference, model inversion i training-data extraction to różne cele, wymagające innych testów i zabezpieczeń. Ograniczenie liczby zapytań pomaga, lecz nie daje gwarancji. Obrona powinna łączyć minimalizację informacji w odpowiedzi, kontrolę kosztu i tożsamości klienta, wykrywanie nietypowych sekwencji, testy prywatności, ochronę artefaktów oraz świadome decyzje o tym, co naprawdę stanowi tajemnicę biznesową.

NIST porządkuje współczesne ataki na systemy uczące się w raporcie Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. Raport obejmuje ataki na prywatność, modele predykcyjne i generatywne, a także ograniczenia dostępnych mechanizmów obronnych. To dobry fundament, ponieważ marketing często wrzuca wszystkie wycieki AI do jednego worka.

Cztery różne pytania atakującego

Klasa	Pytanie	Chroniony zasób
model extraction	„Czy mogę skopiować funkcję modelu?”	własność intelektualna, mechanizm decyzyjny
membership inference	„Czy rekord X był w treningu?”	prywatność osoby lub organizacji
model inversion	„Jakie cechy danych mogę odtworzyć?”	atrybuty i reprezentacje danych
training-data extraction	„Czy model zwróci zapamiętany fragment?”	dokładna treść danych treningowych

Te klasy mogą się łączyć, ale nie są synonimami. Model zastępczy może ułatwić dalsze badanie celu, jednak wysoka zgodność odpowiedzi nie dowodzi odtworzenia oryginalnych parametrów. Membership inference może naruszać prywatność bez ujawnienia pojedynczego rekordu wprost. W raporcie i komunikacji z biznesem trzeba mówić, co dokładnie zostało potwierdzone.

Model extraction: kopiowanie zachowania przez API

W pracy „Stealing Machine Learning Models via Prediction APIs”, zaprezentowanej na USENIX Security 2016, badacze pokazali, że black-box API może wystarczyć do odtworzenia funkcjonalnie zbliżonych modeli dla kilku popularnych klas. Szczególnie wartościowe były odpowiedzi zawierające confidence scores lub bogate informacje o decyzji, lecz autorzy wskazali także, że samo ukrycie confidence nie usuwa całego ryzyka.

Atakujący buduje zbiór zapytań, zbiera etykiety lub wyniki, a następnie uczy surrogate model. Celem może być:

uniknięcie opłat za komercyjne API;
skopiowanie mechanizmu scoringowego lub moderacji;
prowadzenie offline prób omijania detekcji;
poznanie granic decyzyjnych systemu bezpieczeństwa;
stworzenie produktu naśladującego zachowanie usługi.

W generatywnym AI „zgodność” jest trudniejsza do zdefiniowania niż w klasyfikatorze. Model może zmieniać odpowiedzi przez sampling, aktualizację system promptu, narzędzia i RAG. Nadal można kopiować konkretną funkcję, styl, politykę klasyfikacji albo wyspecjalizowany pipeline. Dlatego ewaluacja LLM musi mierzyć wiele wymiarów, a nie jeden wynik podobieństwa tekstu.

Membership inference: prywatność pojedynczego rekordu

Pionierska praca „Membership Inference Attacks Against Machine Learning Models”, opublikowana na IEEE Symposium on Security and Privacy 2017, bada pytanie: czy na podstawie dostępu do modelu można rozpoznać, że dany rekord należał do zbioru treningowego? Różnice w zachowaniu wobec przykładów znanych i nieznanych mogą tworzyć sygnał statystyczny.

Znaczenie zależy od kontekstu. Informacja, że konkretny rekord należał do zbioru pacjentów danej kliniki, uczestników programu pomocowego lub ofiar oszustwa, może sama w sobie być wrażliwa. Atak nie musi odtworzyć pełnego rekordu, aby naruszyć prywatność.

Ryzyko zwykle rośnie, gdy model przeucza się, zwraca szczegółowe rozkłady prawdopodobieństwa, a atakujący ma dobre dane pomocnicze. Nie oznacza to prostego równania „brak overfittingu = brak wycieku”. Wymagana jest empiryczna ocena na realistycznym modelu zagrożeń.

Inversion i extraction danych treningowych

Model inversion dąży do odtworzenia informacji o cechach lub reprezentatywnych danych na podstawie wyjść modelu. Training-data extraction skupia się na uzyskaniu konkretnych, zapamiętanych treści. W modelach generatywnych szczególnie ważne są rzadkie, powtarzane lub unikalne ciągi, ale ryzyko zależy od danych, procesu treningu i interfejsu.

Nie każdy podobny fragment jest dowodem zapamiętania. Model może wygenerować popularne zdanie z rozkładu języka albo skopiować treść dostarczoną w bieżącym kontekście RAG. Test musi kontrolować źródła kontekstu, wersję modelu, temperaturę i obecność dokumentu w indeksie. Audyt bezpieczeństwa AI powinien rozdzielić wyciek z wag od błędu uprawnień w RAG.

Model zagrożeń dla firmowego API AI

Zacznij od zasobów. Czy wartość stanowią wagi, dataset, system prompt, polityka bezpieczeństwa, dane z RAG, embeddingi, etykiety eksperckie czy cały workflow? Model bazowy dostępny publicznie może nie być tajemnicą, ale fine-tuning na danych branżowych i otaczające go reguły już tak.

Następnie określ możliwości atakującego:

anonimowy dostęp czy zweryfikowane konto;
twarde etykiety, confidence scores, logprobs, embeddingi lub token streaming;
liczba i koszt zapytań;
możliwość tworzenia wielu kont;
znajomość domeny i dostęp do podobnego modelu bazowego;
obserwacja wielu wersji usługi;
możliwość przesyłania wsadowych lub adaptacyjnych zapytań.

Na końcu zdefiniuj sukces. „Kradzież modelu” bez metryki jest nietestowalna. Dla klasyfikatora może to być agreement na niezależnym zbiorze, dla rankera korelacja porządku, dla systemu moderacji zdolność przewidywania decyzji, a dla LLM zgodność na prywatnym zestawie zadań.

Jak testować bez naruszania danych

1. Użyj wydzielonego modelu lub tenantów testowych

Test prywatności na produkcyjnych danych może sam stworzyć incydent. Przygotuj canary records, syntetyczne próbki i model o znanym składzie zbioru. W membership inference potrzebujesz przykładów członkowskich i nieczłonkowskich oraz oceny false positive rate, nie kilku efektownych trafień.

2. Ustal budżet zapytań

Budżet jest częścią modelu zagrożeń. Zmierz jakość modelu zastępczego względem liczby zapytań i kosztu. Nie omijaj limitów wieloma kontami bez wyraźnego zezwolenia. Celem jest znalezienie progu ryzyka i sygnałów detekcyjnych.

3. Kontroluj zmienne

Zapisuj wersję modelu, parametry generacji, prompt systemowy, narzędzia i snapshot indeksu RAG. Bez tego nie odróżnisz wycieku z modelu od zmiany pipeline’u. AI red teaming powinien być reprodukowalnym eksperymentem, nie kolekcją przypadkowych promptów.

4. Mierz kilka rodzajów skutku

Dla extraction mierz fidelity, koszt i przenoszalność ataków na model zastępczy. Dla membership inference raportuj ROC/AUC, true positive rate przy niskim false positive rate i przedziały ufności. Dla danych generatywnych dokumentuj dokładność fragmentu, jego unikalność i dowód pochodzenia.

5. Zatrzymaj się przed realną eksfiltracją

Użyj canary strings i kontrolowanych rekordów. Jeżeli test wskazuje możliwość wydobycia prawdziwych danych, nie rozszerzaj go na dane klientów. Przejdź do izolowanego środowiska i uruchom procedurę reagowania.

Warstwowa ochrona przed extraction

Minimalizuj informację w odpowiedzi

Zwracaj tylko dane potrzebne klientowi. Confidence scores, logprobs, embeddingi, surowe uzasadnienia i szczegółowe kody błędów zwiększają użyteczność, ale mogą również zwiększyć sygnał. Decyzja powinna wynikać z produktu, a nie z automatycznej zasady „ukryj wszystko”. W niektórych atakach twarda etykieta nadal wystarcza.

Kontroluj tożsamość, koszt i tempo

Rate limiting, quota, rozliczenie i weryfikacja kont zwiększają koszt ataku. Limity muszą obejmować użytkownika, organizację, klucze API i wzorce wielu kont. Użytkownik wykonujący regularny scoring tysiąca rekordów wygląda inaczej niż adaptacyjny klient sondujący granicę decyzji.

Wykrywaj sekwencje, nie pojedynczy prompt

Sygnały obejmują nietypowe pokrycie przestrzeni wejścia, małe perturbacje wokół granicy, równomierne próbkowanie klas, rosnącą entropię i skoordynowane konta. Monitoring powinien chronić prywatność i unikać przechowywania całych wrażliwych promptów. Obserwowalność systemów AI musi łączyć zdarzenia z wersją modelu i tenantem.

Ogranicz wpływ skopiowanego modelu

Nie opieraj zabezpieczenia transakcji wyłącznie na tajności klasyfikatora. Jeżeli kopia umożliwia offline omijanie fraud detection, zastosuj dodatkowe sygnały, reguły serwerowe, rotację cech i kontrolę po decyzji. Security through obscurity nie może być jedyną barierą.

Ochrona prywatności treningu

Minimalizuj i klasyfikuj dane przed treningiem. Usuń niepotrzebne identyfikatory, duplikaty i sekrety. Dokumentuj podstawę użycia oraz retencję. Dostęp do datasetu, checkpointów i logów ewaluacyjnych powinien być rozdzielony i audytowany.

Regularizacja, early stopping i ograniczenie szczegółowości odpowiedzi mogą redukować część sygnału, ale nie są formalną gwarancją prywatności. Differential privacy może zapewniać mierzalny budżet prywatności przy poprawnie zaprojektowanym treningu, kosztem użyteczności, złożoności i konieczności zarządzania parametrami. Nie należy deklarować „DP” tylko dlatego, że dodano szum do wyniku.

Testy prywatności powinny wejść do release gate obok jakości i bezpieczeństwa. Bezpieczeństwo AI w firmie wymaga właściciela ryzyka, kryteriów akceptacji i procedury na wypadek wykrycia wycieku.

Watermarking i fingerprinting: dowód, nie tarcza

Znaki wodne i fingerprinting mogą pomóc rozpoznać skopiowany model albo wykazać pochodzenie odpowiedzi. Ich skuteczność zależy od założeń, a adaptacyjne modyfikacje, fine-tuning lub destylacja mogą osłabiać sygnał. Nie traktuj ich jako mechanizmu, który uniemożliwia extraction.

Warto rozdzielić prewencję, detekcję i egzekwowanie. Quota zwiększa koszt, telemetryka wykrywa podejrzaną kampanię, fingerprint wspiera analizę, a umowy i kontrola dostępu określają dozwolone użycie. Żadna z tych warstw samodzielnie nie gwarantuje poufności funkcji udostępnionej przez API.

Reagowanie na podejrzenie kradzieży modelu

Zachowaj logi zapytań, tożsamości, wersji modelu i decyzji limitera.
Oddziel normalny wzrost użycia od adaptacyjnego próbkowania.
Zablokuj lub ogranicz klucze zgodnie z procedurą, nie niszcząc dowodów.
Oceń, czy wyciek dotyczy funkcji modelu, danych, promptu czy RAG.
Zmień exposure: format odpowiedzi, quota, dostęp do logprobs lub endpointu.
Przetestuj ponownie ten sam scenariusz i monitoruj konta powiązane.
Uruchom obowiązki prawne, jeżeli mogły zostać ujawnione dane osobowe.

Nie zawsze trzeba rotować cały model. Jeżeli problemem jest publiczna funkcja scoringowa, sama zmiana wag może dać krótką przerwę, ale nie naprawi interfejsu. Jeżeli wyciekają dane, potrzebna jest analiza datasetu, treningu i wszystkich kopii checkpointów.

Checklista

Czy wiemy, co w systemie AI jest tajemnicą: wagi, dane, prompt czy workflow?
Czy API zwraca więcej informacji, niż klient faktycznie potrzebuje?
Czy quota obejmuje użytkownika, organizację i skoordynowane konta?
Czy detekcja analizuje sekwencje zapytań i wersję modelu?
Czy testy membership inference używają miar przy niskim false positive rate?
Czy canary records pozwalają testować bez danych klientów?
Czy prywatność ma kryteria release gate i właściciela ryzyka?
Czy reakcja rozróżnia extraction funkcji od wycieku danych treningowych?

Udostępnienie modelu przez API jest świadomą wymianą: produkt daje klientowi użyteczną funkcję, a każda odpowiedź ujawnia część zachowania. Zadaniem bezpieczeństwa nie jest obiecać niemożliwą tajność, lecz ograniczyć nadmiar informacji, podnieść koszt nadużycia, wykryć kampanię i chronić dane. Zamów audyt bezpieczeństwa AI — przygotujemy model zagrożeń i testy poufności dopasowane do Twojego API.