Safety Case
Jak działa
Safety case buduje się zwykle metodą zbliżoną do Goal Structuring Notation: zaczyna się od nadrzędnego twierdzenia (np. „wdrożenie tego systemu nie spowoduje katastrofy w danym kontekście”), które rozkłada się na coraz bardziej szczegółowe twierdzenia cząstkowe. Każde twierdzenie łączy się z dowodami przez jawny argument (reguła wnioskowania), a dowody pochodzą z ewaluacji zdolności, testów red-team, badań interpretowalności, pomiarów skuteczności zabezpieczeń i środków kontroli. W ujęciu Clymera i in. argumenty należą do czterech kategorii: (1) inability — system nie ma zdolności, by spowodować katastrofę; (2) control — nawet jeśli ma zdolności, środki kontroli uniemożliwiają ich użycie; (3) trustworthiness — system nie użyłby zdolności szkodliwie, bo jest godny zaufania; (4) deference — poleganie na ocenie wiarygodnych doradców AI. Argumenty można łączyć; całość jawnie wymienia założenia i warunki brzegowe (zakres zastosowania, środowisko), a safety case wymaga aktualizacji, gdy system lub kontekst jego użycia się zmieniają.
Rozwiązany problem
Pojedyncze ewaluacje i benchmarki pokazują wyizolowane zdolności lub zachowania modelu, ale same w sobie nie dowodzą, że system jako całość nie spowoduje poważnej szkody w rzeczywistym wdrożeniu. Safety case spina rozproszone dowody w jeden jawny, falsyfikowalny argument, ujawnia leżące u jego podstaw założenia i luki oraz daje regulatorom i decydentom przejrzystą podstawę do decyzji o trenowaniu lub wdrożeniu systemu.
Komponenty
Nadrzędne twierdzenie o bezpieczeństwie rozłożone na hierarchię twierdzeń cząstkowych, które razem mają uzasadnić akceptowalny poziom ryzyka.
Jawne reguły wnioskowania łączące dowody z twierdzeniami. W ujęciu Clymera i in. dzielą się na cztery kategorie uzasadnień bezpieczeństwa.
Empiryczne podstawy argumentu: wyniki ewaluacji zdolności, testów red-team, badań interpretowalności oraz pomiary skuteczności zabezpieczeń i środków kontroli.
Ewolucja
Safety case funkcjonuje jako wymagany argument bezpieczeństwa w branżach takich jak lotnictwo, energetyka jądrowa, kolej i przemysł offshore (np. brytyjskie Offshore Installations (Safety Case) Regulations 1992).
Clymer, Gabrieli, Krueger i Larsen proponują ramy porządkujące safety case dla AI oraz cztery kategorie argumentów: inability, control, trustworthiness, deference.
Balesni, Hobbhahn i in. (Apollo Research) proponują, jak konstruować safety case oparte na ewaluacjach dla ryzyka ukrytej schematyzacji (scheming) systemów AI.
Brytyjski AI Safety Institute (Goemans, Buhl, Irving i in.) publikuje konkretny szablon safety case dla frontier AI oparty na argumencie o braku zdolności cyberofensywnych.