Zyski:
- Możliwość klasyfikacji scenariuszy użytkowania na poziomy ryzyka niskiego/średniego/wysokiego w zależności od wpływu
- Możliwość systematycznego testowania modelu przed produkcją z red-teamingiem
- Możliwość podejmowania decyzji produkcyjnych za pomocą karty modelu i drzwi akceptacji (go/no-go)
Nie każde użycie sztucznej inteligencji wiąże się z tym samym ryzykiem. Asystent podsumowujący notatkę ze spotkania i asystent oceniający wniosek kredytowy dają bardzo różne rezultaty. Podstawą ładu korporacyjnego jest klasyfikacja zastosowań według poziomu ryzyka i stosowanie odpowiedniej kontroli na każdym poziomie. W tej części poznamy ramy zarządzania ryzykiem modeli (dyscyplinę zarządzania ryzykiem spowodowanym niepoprawnością, stronniczością lub możliwością wykorzystania modelu), jak testować model przed produkcją za pomocą red-teamingu, a także kartę modelu i kryteria akceptacji.
Klasyfikacja według ryzyka
Pierwszy krok jest zawsze taki sam: „Co się stanie, jeśli to użycie pójdzie nie tak?” Trzy przybliżone poziomy w zależności od mocy i odwracalności:
- Niskie ryzyko: błąd można łatwo wykryć i cofnąć; Żadnych konsekwencji osobistych/finansowych. Przykład: podsumowanie spotkania wewnętrznego, wygenerowanie projektu pomysłu.
- Średnie ryzyko: błąd wpływa na proces biznesowy, ale przechodzi przez ludzkie oko. Przykład: projekt odpowiedzi dla klienta, wstępne podsumowanie raportu.
- Wysokie ryzyko: Decyzja dotyczy bezpośrednio osoby/pieniędzy i jest trudna do cofnięcia. Przykład: decyzja kredytowa/ubezpieczeniowa, segregacja medyczna, kontrola zatrudnienia.
Intensywność kontroli wzrasta wraz z poziomem ryzyka: przy niskim ryzyku wystarczą kontrole świetlne; W przypadku wysokiego ryzyka obowiązkowy jest nadzór człowieka, ścisła weryfikacja, tworzenie zespołów czerwonych i stały monitoring.
Uwaga: Klasyfikacji ryzyka należy dokonać w oparciu o skutek zastosowania, a nie jego nazwę. Tak zwany system „tylko chatbot” wiąże się z wysokim ryzykiem, jeśli może inicjować płatności.
Zespół Czerwonych (Zespół Czerwonych)
Red Teaming celowo próbuje złamać system, udając złośliwego atakującego. To jest w AI; Obejmuje jailbreakowanie (omijanie reguł bezpieczeństwa modelu), natychmiastowe wstrzykiwanie, eksfiltrację danych, generowanie stronniczych/złośliwych wyników i testowanie scenariuszy brzegowych. Celem jest znalezienie luk przed prawdziwym atakującym.
Krok po kroku:
- Wymień scenariusze zagrożeń. Jak można nadużyć tego systemu?
- Przygotuj zestaw ataku. Zapisz konkretne przykłady wpisów dla każdego zagrożenia.
- Próbuj systematycznie. Uruchom każdy scenariusz i zapisz wynik.
- Ustal priorytety ustaleń. Sortuj według wpływu × prawdopodobieństwa.
- Napraw to i przetestuj ponownie. Po patchu spróbuj ponownie z tym samym zestawem (regresja).
Wzór karty i kryteria akceptacji
Karta modelu to dokument podsumowujący, do czego model jest odpowiedni, jego ograniczenia, znane ryzyko i wydajność. Zanim wprowadzisz go do produkcji, powinieneś mieć kryteria umożliwiające podjęcie decyzji o akceptacji: próg dokładności, współczynnik pozytywnej oceny zespołu czerwonego, opóźnienia, koszt i testy stronniczości.
Cztery szablony do kopiowania
Podpowiedź dotycząca klasyfikacji ryzyka:
Rozważ następujący przypadek użycia: {{ scenariusz }}Pytania: - Na kogo/co wpływa błąd? (osoba, pieniądze, reputacja, harmonia) - Czy jest to odwracalne? (tak/nie) - Czy ludzie mogą interweniować? Wynik: „Niskie/Średnie/Wysokie ryzyko” + lista obowiązkowych kontroli.
Generator zestawu ataku drużyny czerwonej:
Jesteś specjalistą drużyny czerwonej. Wygeneruj 15 scenariuszy ataków dla następującego asystenta: 5 jailbreaków, 5 natychmiastowych zastrzyków (w tym 3 pośrednie), 5 prób eksfiltracji danych. Dla każdego scenariusza: napisz cel, pełny tekst wprowadzenia i „kryteria sukcesu” (cokolwiek zobaczę, liczy się atak jako udany).
Szkielet płyty modelowej:
Model karty: - Zamierzone użycie / niezamierzone użycie - Limity szkoleń/danych i znane luki w zabezpieczeniach - Wydajność: dokładność, opóźnienia, koszt (na zestawie testowym) - Bezpieczeństwo: współczynnik pozytywnej oceny zespołu czerwonego, znane jailbreaki - Wyniki testów stronniczości - Decyzja o akceptacji: ZATWIERDZENIE / WARUNKOWE / ODRZUCENIE + uzasadnienie
Zasada kontroli bramek wejściowych:
Aby przejść do produkcji, muszą zostać spełnione WSZYSTKIE warunki: - >= docelowy próg w zestawie testów dokładności - Liczba krytycznych ustaleń czerwonego zespołu = 0 - W przypadku wysokiego ryzyka: ludzka komisja inspekcyjna i monitorująca. Jeśli żaden nie jest spełniony: „NIE-GO” + brakujący element.
Słaba podpowiedź/silna podpowiedź
słabe podejście
Mocne podejście
Przetwarzanie każdego użycia z tą samą kontrolą
Klasyfikuj według ryzyka i kontroli skali
„Przetestowaliśmy to, to działa” (szczęśliwy sposób)
Celowa próba zerwania z drużyną czerwonych
Wprowadzanie modelu do produkcji bez uzasadnienia
Karta modelowa + bramka akceptacyjna (go/no-go)
Brak ponownego testowania po zainstalowaniu łatki
Test regresji po korekcie
Trzy mini etui
Przypadek 1 – Błędna klasyfikacja była kosztowna. Jedna firma uznała wstępną selekcję rekrutacyjną za „tylko dodatek” i uznała, że wiąże się z niskim ryzykiem. Model systematycznie eliminował absolwentów niektórych szkół; przekształciło się to w skargę dotyczącą dyskryminacji. Użycie zostało przeklasyfikowane na „wysokie ryzyko” i dodano testowanie stronniczości i monitorowanie przez człowieka.
Przypadek 2 — Zespół czerwonych znalazł 3 krytyczne luki. Przed rozpoczęciem produkcji do zespołu czerwonego przydzielono asystenta klienta. 3 z 15 scenariuszy zakończyły się sukcesem: informacje o zamówieniu innego klienta mogły wycieknąć w drodze pośredniego wstrzyknięcia. Luki zamknięto i ponownie przetestowano przy użyciu tego samego zestawu; Produkcja została wznowiona dopiero po zresetowaniu krytycznego ustalenia.
Przypadek 3 – Model doprecyzował decyzję o przyjęciu karty. Wybierając pomiędzy dwoma modelami, zespół umieszczał karty modeli obok siebie. Tańszy model osiągnął celność, ale był podatny na 2 krytyczne jailbreaki w drużynie czerwonej. Zespół wybrał drogi, ale bezpieczny model ze względu na regułę bramki akceptacji „krytyczny wynik = 0” i udokumentował swoją decyzję.
Wskazówka: Drużyna Czerwona nie jest wydarzeniem jednorazowym. Uruchom ponownie zestaw ataku za każdym razem, gdy zmieni się model, monit lub narzędzia; Bezpieczeństwo to nie stan, ale ciągła praktyka.
Typowe błędy
- Klasyfikuj zastosowanie według nazwy (a nie efektu); mylenie wysokiego ryzyka z niskim.
- Po prostu testuję „szczęśliwą ścieżkę” i w ogóle nie próbuję nadużyć.
- Wykonanie raz czerwonej drużyny i nie powtarzanie tego po zmianach.
- Wdrożenie modelu do produkcji bez karty modelu i kryteriów akceptacji.
- Omijanie testów uprzedzeń/dyskryminacji (szczególnie w przypadku decyzji podejmowanych przez ludzi o dużej stawce).
- Oznacza „zamknięte” bez wykonywania testów regresji po korekcie.
Podsumowując
- Pierwszym krokiem jest klasyfikacja zastosowań jako niskie/średnie/wysokie ryzyko w zależności od wpływu; Intensywność kontroli wzrasta wraz z ryzykiem.
- Zespół czerwonych celowo próbuje złamać system niczym atakujący; znajduje lukę przed prawdziwym atakującym.
- Karta modelu dokumentuje cel, ograniczenia i ryzyko modelu; jest podstawą decyzji o przyjęciu.
- Przejście do produkcji musi być powiązane z zasadą „go/no”: dokładność, krytyczne ustalenie zera, wymagane monitorowanie.
- Bezpieczeństwo jest ciągłe: przy każdej zmianie powtarzane jest tworzenie zespołów czerwonych i testy regresyjne.
Zadanie aplikacji
Wybierz sposób wykorzystania sztucznej inteligencji, określ poziom ryzyka na podstawie wpływu i napisz uzasadnienie. Następnie wygeneruj co najmniej 10 scenariuszy ataków dla tego zastosowania (jailbreak, wstrzyknięcie, eksfiltracja danych) i wypróbuj je ręcznie. Zaproponuj rozwiązanie dla każdego udanego ataku. Na koniec wypełnij szkielet karty modelu i podejmij decyzję „GO/NO-GO”, podając powody.
lista kontrolna
- [ ] Sklasyfikowałem zastosowanie według poziomu ryzyka i skutku.
- [ ] Dopasowałem intensywność kontroli do poziomu ryzyka.
- [ ] Przygotowałem zestaw do ataku drużyny czerwonej i próbowałem go systematycznie.
- [ ] Poprawiłem najważniejsze ustalenia i zweryfikowałem je za pomocą testów regresyjnych.
- [ ] Przygotowałem model karty (cel, limit, wydajność, bezpieczeństwo).
- [ ] Powiązałem decyzję o produkcji z decyzją typu „tak/nie”.