Bezpieczeństwo AI to przede wszystkim projektowanie systemów
Spotkanie BHP po demonstracji
Demonstracja przebiegła dobrze, jak zwykle. Model przeczytał stos wewnętrznych dokumentów, odpowiedział na pytanie dotyczące polityki, zasugerował kolejny krok i przygotował schludne podsumowanie do akt sprawy. Sala kiwała głowami. Ktoś zapytał, czy można go podłączyć do systemu obiegu pracy. Ktoś inny zapytał, jak szybko. Potem inspektor BHP zapytał, co by się stało, gdyby model się mylił, ale był przekonujący. Sala nagle bardzo zainteresowała się herbatnikami.
To pytanie jest właśnie punktem wyjścia praktycznego bezpieczeństwa AI. Nie w abstrakcji i nie w haśle. W kształcie systemu wokół modelu, który czasem się myli, czasem działa na nieaktualnych danych, czasem jest zbyt pewny siebie, czasem zbyt niepewny, a czasem ma rację z niewłaściwego powodu. Kwestia bezpieczeństwa to nie tylko zachowanie modelu. To także to, co system pozwala temu zachowaniu zrobić.
Model, który tworzy projekt zdania, to jedno ryzyko. Model, który aktualizuje decyzję o świadczeniu, to drugie. Model, który wywołuje narzędzie z prawem zapisu, to trzecie. Model, który kieruje pacjenta, odrzuca roszczenie, zmienia limit kredytowy lub steruje sprzętem, znajduje się w zupełnie innej klasie zagrożenia. Ten sam model może być nieszkodliwy, użyteczny, ryzykowny lub niedopuszczalny w zależności od granic, stanu, dowodów, uprawnień, monitorowania i odzyskiwania. Dlatego bezpieczeństwo AI to w dużej mierze projektowanie systemów.
W tym zdaniu „w dużej mierze” robi ciężką pracę. Badania nad modelami mają znaczenie. Jakość danych ma znaczenie. Metody dopasowania mają znaczenie. Nauka o ewaluacji ma znaczenie. Ale gdy organizacja wdraża AI, bezpieczeństwo staje się kwestią operacyjną. Kto może pytać. Co model może zobaczyć. Co może zmienić. Jaki dowód jest wymagany. Jaki stan jest zachowywany. Co się dzieje, gdy źródła są ze sobą sprzeczne. Kiedy wymagana jest zgoda człowieka. Jak wykrywa się dryf. Jak wycofuje się złą wersję. To pytania projektowe, zanim staną się deklaracjami etycznymi. Deklaracja etyczna może być szczera. System nie wykonuje szczerości.
Bezpieczeństwo to problem kontroli
Kiedy ludzie słyszą „bezpieczeństwo”, często myślą o wartościach, danych treningowych, politykach odmowy i dopasowaniu modelu. To część obrazu, ale wdrożony system potrzebuje też kontroli. Kontrola to coś, co zmienia to, co może się wydarzyć: kontrola dostępu, schemat, limit czasu, próg, zgoda człowieka, piaskownica, limit szybkości, weryfikator, wycofanie, wyłącznik awaryjny, zapis, którego ścieżka obsługi nie może edytować. Kontrole są nudne, dopóki ich nie brakuje. Wtedy stają się tematem całego spotkania.
Bezpieczny system AI zakłada, że model może zawieść, i projektuje otaczającą go infrastrukturę w taki sposób, aby to uwzględnić. Oddziela sugestię od działania. Ogranicza uprawnienia narzędzi. Weryfikuje dowody przed zmianą stanu. Uwidacznia niepewność. Rejestruje wersję modelu i zakres źródeł. Odmawia działania, gdy brakuje wymaganych pól. Daje operatorom możliwość wstrzymania automatyzacji. Traktuje wynik modelu jako kandydata, a nie jako dekret pochodzący z bardzo elokwentnego arkusza kalkulacyjnego.
To zwykła inżynieria bezpieczeństwa z modelem językowym w środku. Lotnictwo, medycyna, kolejnictwo, sterowanie przemysłowe i finanse nauczyły się, że ważne systemy wymagają wielowarstwowych zabezpieczeń, ponieważ żaden komponent nie jest doskonały. Wersja AI wydaje się nowa, ponieważ komponent mówi. Mowa sprawia, że błąd jest społecznie przekonujący. Błędna odpowiedź, która brzmi spokojnie, może łatwiej prześlizgnąć się obok zmęczonego operatora niż migający na czerwono komunikat o błędzie. Projekt zabezpieczeń musi być zatem bardziej uparty niż sama proza.
Projektowanie zabezpieczeń zaczyna się od pytania, na co system może wpływać. Jeśli AI może jedynie tworzyć projekty, bezpieczeństwo koncentruje się na jakości źródeł, kontroli halucynacji, przejrzystości interfejsu użytkownika i przeglądzie. Jeśli może kierować pracą, bezpieczeństwo dodaje śledzenie stanu, integralność kolejki, poziomy usług i ścieżki odwołań. Jeśli może wywoływać narzędzia, bezpieczeństwo dodaje zakresy uprawnień, walidację argumentów, dzienniki transakcji i działania kompensujące. Jeśli może wpływać na prawa lub systemy fizyczne, bezpieczeństwo wymaga dowodów, formalnego przeglądu, ograniczonej autonomii i poważnego planowania incydentów. Model to jedna część. Granica uprawnień to druga.
Granica jest produktem
Najważniejsza linia w systemie AI często nie jest widoczna w interfejsie. To granica między czytaniem a zapisem, rekomendowaniem a decydowaniem, streszczaniem a rejestrowaniem, asystowaniem a działaniem. Słabe granice sprawiają, że nieszkodliwe prototypy stają się niebezpiecznymi usługami. Model, który zaczyna jako pomoc przy tworzeniu projektów, dostaje przycisk do zastosowania projektu. Potem dostaje narzędzie do aktualizacji sprawy. Potem dostaje regułę routingu, bo zespół jest zajęty. Sześć miesięcy później nikt nie potrafi wyjaśnić, które decyzje są zautomatyzowane, a które jedynie wspomagane. To nie jest zła wola. To rozszerzanie zakresu w wygodnych butach.
Dobre granice są jawne i możliwe do sprawdzenia. Model może czytać te źródła, a nie tamte. Może proponować te pola, ale ich nie zatwierdzać. Może wywoływać to narzędzie z tymi argumentami, a nie z dowolnym tekstem. Może kierować sprawy niskiego ryzyka, ale nie sprawy sporne. Może odpowiadać tylko wtedy, gdy dowody są aktualne. Nie może wykorzystywać prywatnych notatek do publicznych wyjaśnień. Nie może przechodzić z jednej dzierżawy, regionu, konta lub podstawy prawnej do innej tylko dlatego, że następny akapit wydawał się pomocny.
Granice muszą być również egzekwowane poza modelem. Instrukcja mówiąca, aby nie zapisywać danych w bazie klientów, nie jest granicą, jeśli narzędzie ma dostęp do zapisu i nie ma bramki. Wiadomość systemowa mówiąca, aby cytować źródła, nie jest granicą, jeśli odpowiedzi można przechowywać bez cytatów. Akapit polityki mówiący, że wymagana jest akceptacja człowieka, nie jest granicą, jeśli przepływ pracy pozwala automatyzacji oznaczyć coś jako zatwierdzone. Instrukcje bezpieczeństwa wewnątrz modelu są przydatne, ale nie wystarczają. System musi utrudniać lub uniemożliwiać niebezpieczne ścieżki.
To właśnie ta nieefektowna praca naprawdę chroni ludzi. Typowane wywołania narzędzi. Wąskie zakresy. Domyślnie tryb tylko do odczytu. Osobne usługi zatwierdzania. Operacje idempotentne. Dzienniki audytu. Wersjonowane polityki. Stany kolejek. Jawne stany odmowy. To słownictwo brzmi, jakby inżynier backendu spędził cichy weekend z listą kontrolną. Dobrze. Bezpieczeństwo w produkcji zwykle tak wygląda. Nie stara się wygrać konkursu na hasło reklamowe.
Stan to miejsce, w którym bezpieczeństwo staje się realne
Rozmowy z AI mogą sprawiać wrażenie, że systemy są bezstanowe. Użytkownik pyta, model odpowiada, ekran się zmienia. Produkcja nie jest bezstanowa. Sprawy się przesuwają. Zgłoszenia się starzeją. Uprawnienia wygasają. Dokumenty są poprawiane. Zmienia się wersja modelu. Człowiek odrzuca rekomendację. Wpływa odwołanie. Użytkownik pyta, dlaczego coś się stało w zeszłym miesiącu. Bezpieczeństwo zależy od tego, czy system zachował stan potrzebny do udzielenia odpowiedzi.
Stan mówi systemowi, co już się wydarzyło i co może się wydarzyć dalej. Bez niego model widzi wycinek i zgaduje resztę. Tak powstają zduplikowane działania, znikające terminy, zakładane zatwierdzenia i ponowne wprowadzanie starych dowodów do nowej decyzji. Bezpieczny przepływ pracy rejestruje jawne stany: szkic, brak dowodów, zablokowane przez politykę, wymagany przegląd, zatwierdzony, wykonany, zakwestionowany, poprawiony, wycofany. Te stany nie są dekoracją. Zapobiegają traktowaniu procesu o konsekwencjach jak czatu z ambicjami.
Stan daje też ludziom przewagę. Operator może sprawdzić, dlaczego sprawa jest w przeglądzie. Menedżer może zobaczyć, czy automatyzacja tworzy zaległości. Audytor może odtworzyć, które wersje źródeł były aktywne. Użytkownik może zakwestionować wynik czymś solidniejszym niż zrzut ekranu. Deweloper może zmierzyć, czy nowy model zwiększa odmowy, eskalacje lub przeróbki. Bez stanu każda rozmowa o bezpieczeństwie staje się teatrem. Ludzie mówią o odpowiedzialności, ale system zgubił rzeczowniki.
W przypadku AI stan powinien obejmować wersję modelu i polityki, identyfikator promptu lub szablonu, zestaw źródeł, znacznik czasu pobrania, wywołania narzędzi, pewność lub niepewność, powód odmowy, działanie człowieka i efekt w dalszym ciągu. Nie wszystko to należy do jednej linii logu i nie wszystko powinno być widoczne dla wszystkich. Prywatność i bezpieczeństwo mają znaczenie. Ale informacje muszą istnieć pod kontrolowanym dostępem. W przeciwnym razie bezpieczeństwo zależy od pamięci, a pamięć to znana zła baza danych z doskonałymi wymówkami.
Dowody to szyna bezpieczeństwa
Odpowiedź modelu jest bezpieczniejsza, gdy jest powiązana z dowodami. Brzmi to oczywiście, dopóki system nie jest pod presją. Dowody są pomijane, bo dodają opóźnienia. Cytaty są przechowywane jako tekst, a nie identyfikatory. Wyniki wyszukiwania nie są zachowywane. Wersje źródeł są nadpisywane. Model pisze pewne wyjaśnienie na podstawie dokumentu, który od tego czasu został poprawiony. Później wszyscy pytają, dlaczego odpowiedź była błędna. Odpowiedź brzmi: szyna była dekoracyjna.
Przydatny dowód nie jest przypisem. Jest łańcuchem. Żądanie weszło z tożsamością i celem. Źródła zostały wybrane na podstawie uprawnień. Wyszukiwanie znalazło konkretne fragmenty lub rekordy. Model wygenerował wynik pod nazwaną wersją. Weryfikator sprawdził twierdzenia lub progi. Człowiek zaakceptował, edytował lub odrzucił. Działanie zmieniło stan. System przechował wystarczającą część tego łańcucha, aby można go było odtworzyć lub zakwestionować. To nie jest biurokracja dla samej siebie. To sposób, w jaki bezpieczeństwo przetrwa czas.
Dowody chronią również model przed proszeniem go o niemożliwą pracę. Jeśli system wymaga aktualnych źródeł, model może odrzucić nieaktualne dane wejściowe. Jeśli system wymaga dwóch zgodnych rekordów, może wskazać rozbieżność. Jeśli system wymaga identyfikatorów źródeł, może zatrzymać niepoparte twierdzenia. Model nie musi już zamieniać brakujących dowodów w płynne zarządzanie niepewnością. Może zwrócić bezpieczny stan. To jest łagodniejsze dla modelu i znacznie łagodniejsze dla osoby, której dotyczy wynik.
Istnieje równowaga. Przechwytywanie dowodów nie powinno stać się inwigilacją. Wrażliwe treści mogą być hashowane, redagowane, rozdzielane lub przechowywane przez ograniczone okresy. Nie chodzi o rejestrowanie wszystkiego na zawsze. Chodzi o zachowanie faktów potrzebnych do zbadania ważnych zachowań. Bezpieczeństwo bez dowodów to tylko zaufanie w ładniejszej marynarce. Może dobrze wyglądać w holu. Nie wytrzymuje w incydencie.
Ludzie potrzebują zaprojektowanej władzy
Człowiek w pętli jest często używany jako magiczne zaklęcie. To nie magia. Zmęczony recenzent ze słabymi dowodami, niejasną polityką i kolejką dwustu spraw to nie system bezpieczeństwa. To osoba postawiona na końcu taśmy produkcyjnej i poproszona o bycie zarządem. Może działać przez chwilę, zwłaszcza jeśli osoba jest doświadczona i uparta. To nie jest projekt.
Władza człowieka musi być konkretna. Które przypadki wymagają przeglądu. Jakie dowody widzi recenzent. Czy recenzent może zmieniać ustrukturyzowane pola, czy tylko zatwierdzać prozę. Czy recenzent wie, czy model był niepewny, czy polityka wymagała eskalacji. Czy rozbieżności są przekazywane do ewaluacji. Czy recenzenci są chronieni przed stronniczością automatyzacji. Czy mogą wstrzymać przepływ pracy. Czy mogą eskalować do specjalisty. Czy mogą zobaczyć podobne wcześniejsze przypadki. Czy mogą wyjaśnić decyzję osobie, której dotyczy. Te szczegóły decydują, czy nadzór człowieka jest prawdziwy, czy ozdobny.
Dobra kontrola to także oddzielenie oceny od pracy biurowej. Ludzie nie powinni tracić czasu na szukanie brakujących identyfikatorów źródła, usuwanie duplikatów ponowień, tłumaczenie prozy modelu na stany przepływu pracy czy zgadywanie, która wersja polityki obowiązywała. System powinien pakować sprawę. Człowiek powinien stosować ocenę tam, gdzie jest potrzebna: sporne znaczenie, wyjątek, proporcjonalność, kontekst, empatia i odpowiedzialność. Jeśli człowiek zajmuje się głównie łataniem luk w infrastrukturze, organizacja pomyliła zatrudnianie ludzi z bezpieczeństwem.
Projekt musi też pozwalać ludziom na sprzeciw wobec automatyzacji bez zamieniania tarcia w karę. Jeśli nadpisanie modelu wymaga ośmiu kliknięć, a zaakceptowanie jednego, interfejs ma politykę. Jeśli eskalacja sprawia, że zespół wygląda na wolny, ludzie będą jej unikać. Jeśli metryki nagradzają tylko przepustowość, przeglądy bezpieczeństwa staną się ceremonialne. Projektowanie systemów obejmuje zachęty, ekrany, kolejki i ustawienia domyślne. Model może nie znać metryki, ale ludzie na pewno ją znają.
Lokalność zmienia ryzyko
To, gdzie odbywa się praca AI, ma znaczenie. System wysyłający każdy dokument do zdalnego modelu ma inne ryzyka niż taki, który wykonuje ekstrakcję blisko danych i wysyła tylko wyprowadzone pole. System przechowujący ślady w usłudze serwującej ma inne ryzyka niż taki, który prowadzi niezależne rejestry audytowe. System polegający na jednym zewnętrznym routerze ma inne opcje odzyskiwania niż taki, który może działać lokalnie w ograniczonym zakresie. Lokalność to nie nacjonalizm z diagramem sieci. To praktyczne pytanie o to, które ryzyka się przemieszczają, gdy przemieszczają się dane, moc obliczeniowa, polityka i dowody.
Część pracy powinna odbywać się blisko wrażliwych danych, bo przenoszenie danych tworzy ekspozycję. Część pracy powinna odbywać się blisko użytkowników, bo opóźnienie wpływa na bezpieczeństwo. Część pracy powinna odbywać się w centralnej usłudze, bo potrzebny jest specjalistyczny przegląd lub sprzęt. Część dowodów powinna być przechowywana z dala od ścieżki serwowania modelu, bo to właśnie ta ścieżka może być przedmiotem dochodzenia. Bezpieczny projekt rzadko jest w pełni lokalny lub w pełni zdalny. To przemyślane rozmieszczenie.
Lokalność wpływa też na odpowiedzialność prawną i organizacyjną. Jeśli wywołanie modelu przekracza regiony, które prawo reguluje dane. Jeśli indeks jest budowany poza systemem źródłowym, jak propagowane są usunięcia. Jeśli dostawca zmienia model, jak odbywa się powiadomienie i testowanie. Jeśli logi znajdują się w portalu dostawcy, czy organizacja może je wyeksportować podczas incydentu. To nie są abstrakcyjne pytania o suwerenność. To pytania o bezpieczeństwo, bo decydują o tym, czy organizacja może kontrolować i wyjaśniać system w warunkach stresu.
Złe rozmieszczenie może sprawić, że bezpieczne zachowanie będzie kosztowne. Jeśli każdy krok weryfikacji wymaga zdalnej podróży w obie strony, zespoły mogą próbkować zamiast sprawdzać każdy przypadek. Jeśli dane audytowe są trudne do połączenia, dochodzenia stają się powolne. Jeśli prywatne dane muszą podróżować w celu prostej klasyfikacji, ryzyko rośnie bez żadnych korzyści. Dobry projekt lokalności obniża koszt robienia rzeczy bezpiecznej. To ma znaczenie, bo kontrole, które są zbyt kosztowne, w końcu zostaną opisane jako opcjonalne, a tak zaczyna się wiele złych historii.
Ocena musi obejmować cały system
Wiele zespołów ocenia model, a zapomina ocenić system. Sprawdzają, czy odpowiedzi są poprawne na zestawie promptów, a potem wdrażają je do przepływu pracy z uprawnieniami, świeżością źródeł, kolejkami, wywołaniami narzędzi, przeglądem ludzkim, ponownymi próbami i zmieniającymi się politykami. Benchmark modelu może być nadal przydatny, ale nie opisuje już całego ryzyka. Awarie bezpieczeństwa często mieszkają w połączeniach.
Ocena systemu testuje zachowanie end-to-end. Pyta, czy właściwe źródło jest pobierane dla właściwego użytkownika. Sprawdza, czy nieaktualne dane są odrzucane. Weryfikuje, czy wywołania narzędzi są blokowane bez uprawnień. Mierzy, czy przypadki wysokiego ryzyka trafiają do ludzi. Testuje wycofanie. Testuje opóźnienia kolejek. Testuje ścieżki aktualizacji modelu. Testuje dziwne, ale zwykłe przypadki: brak daty, zduplikowany klient, wyjątek regionalny, odwołanie po korekcie, usunięcie źródła, częściowa awaria, przeciążony recenzent. Produkcja ma smak do przypadków, których nikt nie uznał za wystarczająco dramatyczne.
Ocena powinna obejmować zdolność negatywną. System musi być dobry w nie robieniu rzeczy. Nie odpowiadaniu bez dowodów. Nie przekraczaniu granic uprawnień. Nie eskalowaniu do działania, gdy dozwolone jest tylko szkicowanie. Nie ukrywaniu niepewności. Nie używaniu źródła po usunięciu. Nie kontynuowaniu, gdy narzędzie zwraca niespójny stan. Bezpieczeństwo zależy od odmowy i pauzy tak samo jak od dokładności. Najważniejszym wynikiem bezpiecznego systemu AI może być niewystarczająca ilość dowodów, co jest zdaniem, którego żaden zespół demo nigdy nie umieści na banerze.
Ocena systemu zmienia też zarządzanie wydaniami. Zmiana promptu, zmiana modelu, przebudowa indeksu, aktualizacja polityki, zmiana uprawnień narzędzi lub zmiana interfejsu recenzenta mogą zmienić bezpieczeństwo. Każda z nich wymaga zakresu testów i planu wycofania. Zespół powinien wiedzieć, które zachowania się zmieniły i które ryzyka wzrosły. To nudne w ten sposób, w jaki nudne są pasy bezpieczeństwa. Staje się interesujące tylko wtedy, gdy ich brakuje, a wtedy jest już za późno na komfort.
Lekcja
Bezpieczeństwo AI to w większości projektowanie systemów, ponieważ szkoda zwykle podróżuje przez systemy. Wynik modelu staje się ryzykowny, gdy przepływ pracy ufa mu zbyt mocno, brama narzędzi jest zbyt szeroka, brakuje dowodów, stan jest niejasny, przegląd jest przeciążony, logi są słabe, a wycofanie jest fikcyjne. Model może być widocznym źródłem zdania, ale to system decyduje, czy zdanie stanie się działaniem.
Ten obraz jest mniej dramatyczny niż wiele debat o bezpieczeństwie AI, a bardziej przydatny dla organizacji wdrażających systemy już teraz. Zachęca zespoły do wyznaczania granic, nazywania odpowiedzialności, zachowywania dowodów, projektowania stanów, świadomego rozmieszczania pracy, oceny całościowej oraz dawania ludziom realnej władzy. Traktuje model jako potężny element w analizie bezpieczeństwa, a nie jako całą analizę bezpieczeństwa. To jest dojrzałe stanowisko. Daje też inżynierom coś do zbudowania poza kolejnym dokumentem PDF z polityką, co jest miłe dla wszystkich.
Pytanie oficera bezpieczeństwa po prezentacji było dokładnie trafne. Co się stanie, jeśli model się myli, ale jest przekonujący. Bezpieczny system powinien mieć odpowiedź: tutaj może tylko tworzyć szkice, tam musi cytować aktualne źródła, nie może wywołać tego narzędzia, ta sprawa trafia do przeglądu, ta akcja pozostawia potwierdzenie, ten przepływ pracy można wstrzymać, tę wersję można wycofać, tę decyzję można zakwestionować. Te odpowiedzi to nie przeczucia. To projekt.
W AI zawsze będzie niepewność. Praktycznym zadaniem jest powstrzymanie niepewności przed przekształceniem się w nieograniczoną władzę. Osiąga się to za pomocą interfejsów, stanów, mechanizmów kontroli, dowodów, lokalności, oceny, odzyskiwania oraz ludzkiego osądu, który został odpowiednio wyposażony. Innymi słowy, projektowania systemów. Nie dlatego, że wartości nie mają znaczenia, ale dlatego, że wartości muszą zostać przekształcone w wykonalne zasady, zanim będą mogły kogokolwiek chronić.