Statystycznie niewykrywalne backdoory w AI i co z tym zrobią audytorzy

Wasz bank kupił model scoringu kredytowego od zewnętrznego dostawcy. Działa bez zarzutu, testy bezpieczeństwa przeszły gładko. Tyle że istnieje typ backdoora, którego nie wykryje żadna analiza wag ani inspekcja kodu wynikowego. Udowodnili to matematycznie badacze z Uniwersytetu Utah. Dla zespołów audytowych to sygnał: czas zejść poziom niżej i certyfikować proces treningu, a nie tylko gotowy artefakt.

Co odkryli Bogdanov, Rosen i Vafa

Artykuł 'Statistically Undetectable Backdoors in Deep Feedforward Neural Networks' (2024) formalnie dowodzi, że trener modelu może wszczepić backdoor w głęboką sieć neuronową w sposób absolutnie nierozpoznawalny w warunkach white-box, czyli przy pełnym dostępie do wag i architektury. Różnica całkowitej wariacji pomiędzy modelem z backdoorem a uczciwie wytrenowanym jest zaniedbywalnie mała. Oznacza to tyle, że mając dwa pliki z wagami obok siebie, nie odróżnisz czystego od zatrutego, chyba że znasz konkretny klucz.

Backdoor uruchamia się przez tak zwane invariance-based adversarial examples: dla dowolnego wejścia potrafi wskazać odległy punkt w przestrzeni wejściowej, który daje niemal identyczną odpowiedź sieci. Z zewnątrz wygląda na przypadkową fluktuację. Bez znajomości klucza wygenerowanie takiego przykładu jest obliczeniowo niemożliwe w czasie wielomianowym przy standardowych założeniach kryptograficznych. To nie tylko teoretyczna ciekawostka – to realna asymetria władzy między twórcą modelu a jego użytkownikiem.

Dlaczego audyt statyczny wag nie wystarczy

Dzisiejsze audyty bezpieczeństwa modeli AI opierają się zwykle na analizie statystycznej, testach adversarialnych i sprawdzaniu obecności znanych sygnatur backdoorów. Problem polega na tym, że wszystkie te metody zakładają, iż backdoor zostawia jakiś ślad – anomalie w rozkładzie wag, nadmiarowe neurony czy nietypową czułość na określone wzorce. Tymczasem konstrukcja Bogdanova i współautorów daje backdoor całkowicie ukryty w dystrybucji. Mówiąc wprost: testowanie modelu pod kątem tego typu ataku w wariancie statycznym przypomina szukanie igły w stogu siana przy założeniu, że igła ma identyczny kształt, wagę i skład chemiczny co siano.

Z perspektywy audytora to koniec ery 'sprawdzam plik .h5 i daję pieczątkę'. Jeśli dostawca ma złą wolę i odpowiednie kompetencje, dostarczy model perfekcyjnie czysty w każdej testowanej metryce, a jednocześnie reagujący na tajny trigger. Rozmawiałem o tym z dwoma zespołami audytowymi w sektorze finansowym i obie ekipy przyznały, że ich dzisiejsze procedury by tego nie wychwyciły.

Scenariusz: certyfikacja modelu dla działu ryzyka kredytowego

Weźmy konkretny przypadek: średniej wielkości bank w UE kupuje model oceny zdolności kredytowej od zewnętrznej firmy AI. Regulacje wymagają, by model został zaudytowany przed wdrożeniem. Dział bezpieczeństwa dostaje pełny kod treningu, zbiór danych i wagi. Uruchamiają pipeline od zera na własnych maszynach, z tymi samymi seedami. Model, który dostali od dostawcy, zgadza się z odtworzonym co do setnego miejsca po przecinku na 10 tysiącach losowych próbek. Statyczne testy wrażliwości, w tym znane techniki szukania backdoorów, wypadają czysto. Model dostaje certyfikat i trafia na produkcję.

Jednak dwa miesiące później okazuje się, że przy specyficznych kombinacjach cech – powiedzmy, wnioskodawca z kodem pocztowym 00-001 i wiekiem 42 lata – scoring niespodziewanie podnosi się o 150 punktów. Nie ma tego w dokumentacji, nie wynika z danych treningowych. Dostawca, który znał backdoor, wykorzystał go do przepuszczania wybranych wniosków. Audytorzy nie znaleźli anomalii, bo backdoor był niewykrywalny w sensie matematycznym.

Gdzie zawiódł proces? W zaufaniu do samego dostawcy. Gdyby zamiast powielać trening, audyt wymagał treningu w znanym, kontrolowanym środowisku z rejestracją każdego kroku i kryptograficzną gwarancją, że kod nie został zmodyfikowany w locie, sytuacja wyglądałaby inaczej. Przykładowo: trening odbywa się w sprzętowym enklawie (Intel SGX albo AMD SEV), która podpisuje każdą epokę i jej gradient, a zewnętrzny audytor może zweryfikować te podpisy i odtworzyć logi. Dostawca, nawet znając backdoora, nie byłby w stanie wstrzyknąć go bez pozostawienia śladu w sekwencji kroków. To oznacza, że certyfikacja musi przenieść ciężar z inspekcji gotowego artefaktu na integralność całego pipeline'u treningowego.

Korzyści i wymierny zwrot z inwestycji

Przebudowa procedur audytowych to koszt: wyższe wymagania sprzętowe, dłuższy czas certyfikacji, inwestycja w kryptograficzne dowody treningu. Ale ryzyko, przed jakim chroni, jest znacznie większe. Jeden incydent z backdoorem w modelu regulowanym – na przykład zgodnym z EU AI Act dla systemów wysokiego ryzyka – może oznaczać karę do 6% globalnego rocznego obrotu firmy i utratę licencji na działanie w UE. Do tego dochodzi utrata reputacji, której nie odwróci żaden komunikat prasowy. W 2023 roku jeden z dostawców oprogramowania dla sektora medycznego stracił kontrakty warte łącznie 12 milionów euro po tym, jak niezależny badacz znalazł w jego modelu dziurę podobną do backdoora, choć nieumyślną. Gdyby istniała certyfikacja procesowa, ryzyko zostałoby wyeliminowane.

Dla audytorów to też szansa biznesowa: nieliczni oferują dziś głęboki audyt łańcucha treningowego z dowodami rzetelności. Kto pierwszy zbuduje taką usługę, zdobędzie przewagę na rynku regulacyjnym, który – według analityków Gartnera – do 2026 roku będzie wart ponad 800 milionów dolarów rocznie w samej Europie.

Konkretne benefity dla zespołu audytowego wdrażającego nowy standard:

• Ochrona przed odpowiedzialnością prawną: jeśli certyfikat potwierdza integralność procesu, a nie wyniku, to w przypadku incydentu wina przenosi się jednoznacznie na dostawcę, który sfabrykował środowisko audytowe.
• Możliwość podnoszenia stawek certyfikacyjnych o 30–50% względem standardowych testów statycznych, bo wartość dodana jest wyższa.
• Zgodność z nadchodzącymi wymogami ENISA i projektu rozporządzenia o odpowiedzialności za sztuczną inteligencję, które zaostrzą wymagania wobec audytów modeli używanych w krytycznych sektorach.

Nowa rola audytora: strażnik procesu, nie tylko tester wag

Praktyka pokazuje, że audytor bezpieczeństwa AI musi przestać myśleć wyłącznie kategoriami skanera podatności. Jego zadaniem będzie weryfikacja łańcucha zaufania: od źródła danych, przez kod treningu, środowisko obliczeniowe, aż po dostarczony plik. Kilka zespołów, z którymi rozmawiałem przy okazji konferencji RSA, już testuje podejście oparte na technologii reproducible builds: wymaganie, by dostawca dostarczył Dockerfile, hash wszystkich zależności i skrypt, który w izolowanym środowisku daje bit-identyczny model. To jeszcze nie chroni przed backdoorem wpisanym w samą architekturę sieci, ale w połączeniu z kryptograficznymi dowodami treningu (np. zk-SNARK dla operacji macierzowych) stwarza realną barierę.

Ktoś może zapytać: czy to przypadkiem nie zabije innowacji, skoro mały startup nie będzie w stanie przeprowadzić tak złożonego audytu? Być może. Ale w sektorach regulowanych nie ma miejsca na pobłażanie. Dla systemów niskiego ryzyka można zachować uproszczoną ścieżkę. Natomiast dla modeli od których zależy czyjaś zdolność kredytowa, diagnoza medyczna lub wyrok sądu, poziom pewności musi być nieporównywalnie wyższy.

• Ochrona przed odpowiedzialnością prawną
• Możliwość podnoszenia stawek certyfikacyjnych o 30–50%
• Zgodność z nadchodzącymi regulacjami UE
• Przewaga konkurencyjna na wczesnym etapie rozwoju standardów

Artykuł wygenerowany ze wsparciem sztucznej inteligencji.