Bezpieczeństwo — oś oceny Standardu PACT

Co chroni ta oś.

Bezpieczeństwo chroni ludzi, prawa, usługi i organizacje przed niedopuszczalną szkodą, gdy AI działa błędnie, nieprzewidywalnie, niebezpiecznie lub poza zamierzonymi warunkami. Ocena obejmuje normalne działanie, racjonalnie przewidywalne niewłaściwe użycie, zmianę środowiska, awarię komponentu i celowy atak.

Model może spełniać średni benchmark i nadal być niebezpieczny. Szkoda może wynikać z rzadkich błędów, nierównych kosztów pomyłek, słabej integracji, mylących interfejsów, opóźnionej reakcji człowieka, zależności od niedostępnego dostawcy lub manipulowania danymi i promptami przez atakującego. Uzasadnienie bezpieczeństwa musi łączyć wydajność techniczną z realnymi konsekwencjami awarii.

Bezpieczny system ma znane ograniczenia, monitorowane działanie, przetestowane odtwarzanie i organizację gotową zaprzestać jego używania.

Zmapuj zagrożenia przed wyborem wskaźników.

Zagrożenia wyników. Nieprawidłowe, zmyślone, niepełne, nieaktualne, szkodliwe lub nadmiernie pewne wyniki oraz działania, które mogą uruchomić.
Zagrożenia kontekstu. Populacje, języki, środowiska, przypadki graniczne i warunki działania nieuwzględnione w rozwoju ani walidacji.
Zagrożenia czynnika ludzkiego. Uprzedzenia automatyzacji, zmęczenie alarmami, słabe mechanizmy sterowania, niedostępne interfejsy, niejasna niepewność i presja używania systemu poza jego kompetencją.
Zagrożenia integracji. Nieprawidłowe uprawnienia, użycie narzędzi, potoki danych, błędy kaskadowe, kruche zależności i awarie na granicach systemu.
Zagrożenia ochrony. Omijanie zabezpieczeń, zatruwanie, ekstrakcja, ataki na prywatność, wstrzykiwanie promptów, niewłaściwe użycie, nieuprawnione działania i naruszenie łańcucha dostaw AI.
Zagrożenia zmiany. Zmiany modelu, danych, progu, dostawcy, polityki lub środowiska, które unieważniają wcześniejsze testy bez widocznego wydania nowej wersji.

Gdzie bezpieczeństwo najczęściej zawodzi.

Jeden wynik zbiorczy. Wydajność jest uśredniana dla łatwych i trudnych przypadków, przez co ukrywa błędy niosące największą szkodę.
Testowanie wyłącznie modelu. Ewaluacja pomija interfejs, integracje, operatorów, rozwiązanie awaryjne, połączone narzędzia i późniejsze decyzje.
Dane rozwojowe ponownie użyte jako dowód. Te same założenia i dane kształtują zarówno system, jak i dowody użyte do jego walidacji.
Brak modelu niewłaściwego użycia. Zespoły testują zamierzone prompty i dane wejściowe, lecz nie prawdopodobne błędy, działania antagonistyczne ani użycie poza określonymi granicami.
Monitorowanie bez progów. Logi i pulpity istnieją, lecz żaden wynik nie wymusza dochodzenia, wycofania wersji, powiadomienia ani zawieszenia.
Reakcja na incydent bez specyfiki AI. Ogólne procedury IT nie obejmują wycofania modelu, ograniczenia szkodliwych wyników, zatrucia danych, naruszenia promptów lub wyszukiwania ani środków naprawczych dla osób dotkniętych skutkami.
Niebezpieczna zależność. Usługa nie może działać, gdy dostawca, sieć lub model są niedostępne albo zmienione bez powiadomienia.

Pytania oceny.

Jakie szkody są prawdopodobne dla każdego zastosowania, objętej grupy i granicy systemu, w tym przy niewłaściwym użyciu i działaniu złośliwym?
Które szkody są niedopuszczalne niezależnie od prawdopodobieństwa i kto zatwierdził tolerancję pozostałego ryzyka?
Czy testy reprezentują rzeczywiste populacje, języki, przypadki graniczne, obciążenia szczytowe, pogorszone dane wejściowe i warunki używania systemu?
Czy wskaźniki są powiązane z konsekwencjami różnych błędów, a niepewność i wyniki podgrup są raportowane zamiast jednej średniej?
Jak ocenia się zagrożenia ochrony, prywatności i niewłaściwego użycia w danych, modelach, promptach, wyszukiwaniu, narzędziach, infrastrukturze i dostawcach?
Które sygnały ujawniają dryf, pogorszenie, nieoczekiwane użycie lub pojawiającą się szkodę i jakie progi uruchamiają działanie?
Czy organizacja może odizolować, wycofać, wyłączyć lub zastąpić system bez powodowania kolejnej szkody?
Jak osoby dotknięte skutkami zostaną powiadomione i wsparte oraz jak otrzymają środek naprawczy po istotnej awarii?

Dowody do zebrania.

Definicja systemu: Zamierzony cel, użytkownicy, osoby objęte skutkami, architektura, zależności danych i modeli, interfejsy, uprawnienia, granice użycia i zastosowania zakazane.
Rejestr zagrożeń: Zagrożenie, przyczyna, objęta grupa, dotkliwość, prawdopodobieństwo, wykrywalność, odwracalność, kontrola, właściciel i ryzyko rezydualne, w tym znane i przewidywalne niewłaściwe użycie.
Plan ewaluacji: Niezależne i powtarzalne testy wydajności, niepewności, odporności, ochrony, czynników ludzkich, integracji, dostępności i scenariuszy operacyjnych.
Wyniki testów: Wyniki z podziałem, nieudane przypadki, granice ufności, adekwatność benchmarku, ustalenia red team, skuteczność zabezpieczeń i nierozstrzygnięta niepewność.
Plan monitorowania: Sygnały, wartości bazowe, częstotliwość przeglądu, progi alarmowe, właściciele, droga dochodzenia i wyraźne kryteria wycofania, ograniczenia lub zawieszenia.
Dowody odtwarzania: Wyniki ćwiczeń dotyczących ograniczania szkody, rozwiązania manualnego, wycofania modelu lub konfiguracji, awarii dostawcy, powiadomienia, środka naprawczego i bezpiecznego wycofania systemu.

Progi decyzyjne.

Kontynuuj: Zagrożenia są powiązane z dowodami i zabezpieczeniami; testy reprezentują rzeczywiste warunki; ryzyko rezydualne jest wyraźnie zaakceptowane; monitorowanie i odtwarzanie mają mierzalne sygnały oraz przetestowanych właścicieli.
Kontynuuj warunkowo: Niepewność jest ograniczona przez zawężenie populacji, celu, czasu, uprawnień lub potwierdzenie człowieka, wraz z planem dowodowym i automatycznym wygaśnięciem.
Zatrzymaj lub przeprojektuj: Prawdopodobna awaria może spowodować niedopuszczalną lub nieodwracalną szkodę; istotnej wydajności nie można zmierzyć; krytyczne ryzyka ochrony lub integracji pozostają niekontrolowane; albo systemu nie można bezpiecznie ograniczyć, wycofać lub zastąpić.

Mierz skuteczność zabezpieczeń, nie ich samą obecność. Filtr, osoba oceniająca, ostrzeżenie lub wyłącznik awaryjny liczą się dopiero wtedy, gdy reprezentatywne testy pokażą, jakiej szkodzie zapobiegają, gdzie zawodzą i jak szybko organizacja może zareagować.

Kontrole cyklu życia.

Przed pierwszym użyciem

Określ zamierzone warunki i niedopuszczalne szkody, przeprowadź niezależną ewaluację, przećwicz procedury incydentowe i awaryjne oraz ogranicz uprawnienia do minimalnego poziomu konsekwencji uzasadnionego dowodami.

Podczas działania

Śledź wydajność, dryf, niebezpieczne wyniki, wzorce odstępstw, sygnały ochrony, zdarzenia potencjalnie wypadkowe i skargi. Badaj odchylenia względem wcześniej uzgodnionych progów, a nie dopiero po publicznym incydencie.

Gdy zmieniają się warunki

Wymagaj kontroli zmian i ponownej walidacji po zmianie modelu, danych, dostawcy, promptu, źródła wyszukiwania, narzędzia, uprawnienia, progu, grupy użytkowników lub środowiska. Monitoruj zmiany stron trzecich, które mogą nastąpić bez lokalnego wdrożenia.

Źródła i dalsza lektura.

Źródła pierwotne i instytucjonalne przeanalizowane na potrzeby tego dokumentu roboczego. Zastosowanie prawne należy ocenić dla konkretnego systemu i kontekstu.