Czego Europa może nauczyć się z analiz bezpieczeństwa

A safety case is a living argument from hazards and assumptions to evidence, residual risk and a decision. It offers AI teams a more honest release...

Czego Europa może nauczyć się z analiz bezpieczeństwa

Plik, który musi odpowiedzieć, zanim pociąg ruszy

Europejskie przepisy kolejowe zaczynają się od mało efektownego pytania: co się zmieniło. Zmiana może mieć charakter techniczny, operacyjny lub organizacyjny. Może dotyczyć sprzętu, procedury, obsady kadrowej lub interfejsu między organizacjami. Wspólna metoda bezpieczeństwa dla oceny ryzyka i wyceny ryzyka wymaga, aby wnioskodawca ocenił znaczenie tej zmiany, zastosował proces zarządzania ryzykiem, gdy jest to wymagane, oraz skorzystał z niezależnego organu oceniającego, który sprawdzi, czy proces i jego wyniki zostały zastosowane prawidłowo. Przepis nie interesuje się tym, czy zmiana została ogłoszona z przekonaniem. Interesuje go to, czy argument za dalszym prowadzeniem działalności można poddać kontroli.

Ten nawyk warto przenieść do AI. System nie staje się bezpieczny dlatego, że jego model jest sprytny, interfejs spokojny, a dostawca przygotował ładny raport z testów. Staje się obronny dla określonego zastosowania, gdy organizacja potrafi wyjaśnić, co twierdzi, jakie zagrożenia stoją za tym twierdzeniem, jakie założenia umożliwiają to twierdzenie, jakie dowody wspierają każde ogniwo, kto przyjął pozostałe ryzyko i co mogłoby wznowić decyzję. Wynik nazywa się powszechnie safety case: ustrukturyzowanym argumentem popartym dowodami, ograniczonym warunkami i utrzymywanym w trakcie zmian.

Safety case to nie opowieść o wyimaginowanym wypadku. To sposób na odmowę obarczania wypadku całym ciężarem dowodów. Zadaje trudne pytania, gdy projekt, zakupy i praktyka operacyjna mogą się jeszcze zmienić. To czyni go użytecznym dla kolei, lotnictwa, wyrobów medycznych, sterowania przemysłowego i infrastruktury krytycznej. Jest też użyteczny dla AI, gdzie komponent może być jednocześnie imponujący statystycznie i niegotowy operacyjnie. Model może zdać test, podczas gdy system wokół niego nie ma bezpiecznej odpowiedzi na niepewność, odpowiedzialnego operatora ani drogi do naprawienia złej decyzji.

To rozróżnienie ma znaczenie w Europie, ponieważ akt w sprawie sztucznej inteligencji już wymaga, aby systemy wysokiego ryzyka funkcjonowały w ramach ciągłego, udokumentowanego procesu zarządzania ryzykiem. Artykuł 9 opisuje iteracyjną identyfikację, szacowanie, ocenę i postępowanie z ryzykiem w całym cyklu życia systemu, w tym racjonalnie przewidywalne niewłaściwe użycie oraz informacje z monitorowania po wprowadzeniu do obrotu. Artykuł 11 wymaga dokumentacji technicznej przed wprowadzeniem systemu do obrotu i stanowi, że musi być ona aktualizowana. Te przepisy nie używają safety case jako uniwersalnej etykiety. Opisują jednak nawyki, które czynią safety case wiarygodnym.

Safety case sprawia, że droga od twierdzenia o bezpieczeństwie do decyzji o wydaniu jest na tyle widoczna, że można ją zakwestionować.

Safety case to nie raport z testów

Raport z testów odpowiada na pytanie o test. Opisuje, co było testowane, w jakich warunkach, z jakim wynikiem i, jeśli praca jest dobra, z jakimi ograniczeniami. To jest wartościowe. Przypadek bezpieczeństwa stawia inne pytanie: czy istnieje wystarczająco poparty argument, że ten system jest akceptowalny do tego celu, w tym kontekście, z tymi ludźmi, kontrolami i pozostałym ryzykiem. Wynik testu może być jednym z elementów tego argumentu. Nie może po cichu stać się całym argumentem tylko dlatego, że tabela ma zielone komórki.

Zakładając, że klasyfikator został przetestowany na oznakowanym zbiorze danych. Raport może nam powiedzieć, jak sobie poradził na tym zbiorze, być może według klasy, progu lub punktu operacyjnego. Sam w sobie nie mówi nam, czy dane wejściowe docierające w produkcji mają to samo znaczenie, czy dotknięta populacja jest reprezentowana, czy recenzent może rozpoznać słaby wynik, czy odwołanie jest możliwe, czy dostawca może zmienić model bez powiadomienia, lub czy organizacja może zatrzymać i cofnąć działanie podejmowane w dalszej kolejności. Te pytania należą do systemu i jego użytkowania, nie tylko do komponentu.

Przeciwny błąd jest również powszechny. Duży plik zapewnienia może zawierać setki stron i nadal nie stanowić argumentu. Katalog testów, polityk i notatek ze spotkań nie jest przypadkiem bezpieczeństwa, jeśli żadne twierdzenie ich nie łączy. Dowody potrzebują zadania. Test może wspierać twierdzenie o solidności. Opis roli może wspierać twierdzenie o autorytecie. Ćwiczenie wycofania może wspierać twierdzenie o odzyskiwaniu. Ślad audytu może wspierać twierdzenie o możliwości śledzenia. Bez relacji twierdzenie-dowód, plik jest archiwum działań, a nie wyjaśnieniem bezpieczeństwa.

Dlatego przypadek bezpieczeństwa może być w jednym miejscu krótszy niż raport z testów, a w innym większy. Rozrasta się wokół zagrożeń i decyzji. Narzędzie do tworzenia treści o niskich konsekwencjach może potrzebować skromnego argumentu obejmującego zakres, przetwarzanie danych, przegląd i korektę. System podłączony do decyzji klinicznych, transportowych, finansowych lub dotyczących usług publicznych potrzebuje więcej dowodów, ponieważ więcej osób zależy od wyniku i ponieważ droga do naprawy może być trudna. Rozmiar wynika z konsekwencji i niepewności, a nie z modnej długości karty modelu.

Argument powinien również odróżniać dowody komponentu od dowodów operacyjnych. Dowody komponentu dotyczą modelu, algorytmu lub czujnika w izolacji lub w kontrolowanej integracji. Dowody operacyjne dotyczą rzeczywistego przepływu pracy: dostępu, świeżości danych, przeglądu ludzkiego, kolejek, uprawnień narzędzi, obsługi incydentów i kontroli zmian. Model może być stabilny, podczas gdy kolejka się załamuje. Przepływ pracy może być dobrze zaprojektowany, podczas gdy dostawca zmienia schemat wejściowy. Przypadki bezpieczeństwa zmuszają oba widoki na tę samą stronę, co jest nieco niewygodne, a zatem zdrowe.

Zacznij od twierdzenia, które ma krawędzie

Każdy przypadek bezpieczeństwa zaczyna się od twierdzenia najwyższego poziomu. Twierdzenie powinno być wystarczająco wąskie, aby można je było przetestować, i wystarczająco użyteczne, aby kierować decyzją. Zdanie ten system AI jest bezpieczny nie jest twierdzeniem z krawędziami. Bezpieczny dla kogo, robiąc co, w jakich warunkach i z jakimi kontrolami. Lepsze twierdzenie może mówić, że określona funkcja wspomagania decyzji jest akceptowalna dla nazwanej grupy przeszkolonych operatorów, pod warunkiem że system jest używany wyłącznie do rekomendacji, że dowody i niepewność są pokazane, że człowiek z autorytetem przegląda wynik oraz że dostępne są zdefiniowane ścieżki zatrzymania i korekty.

To zdanie jest mniej chwytliwe i znacznie bardziej wartościowe. Identyfikuje cel, aktora, granicę i warunki. Ujawnia również, co uczyniłoby twierdzenie fałszywym. Jeśli ta sama funkcja jest podłączona bezpośrednio do automatycznej decyzji, twierdzenie już jej nie obejmuje. Jeśli zamierzeni użytkownicy nie są przeszkoleni lub nie mogą zakwestionować wyniku, twierdzenie słabnie. Jeśli źródło danych się zmienia i nie można go prześledzić, dowody dla twierdzenia mogą wygasnąć. Dobre twierdzenie najwyższego poziomu niesie własną listę sposobów na ponowne otwarcie.

Twierdzenia można dekomponować. System pozostaje w ramach swojego zamierzonego przeznaczenia. Dane wejściowe spełniają określone warunki jakości i uprawnień. Interpretacja wyników modelu nie stwarza niebezpiecznego błędu automatyzacji. Działania o wysokiej wadze skutków podlegają przeglądowi proporcjonalnemu do ich ryzyka. Operatorzy mogą zignorować wynik lub go odwrócić. Organizacja jest w stanie wykryć istotne dryfowanie. Zmiana nie jest wdrażana bez sprawdzenia założeń, których dotyczy. Każde podtwierdzenie wymaga mechanizmów kontroli i dowodów. Drzewo nie jest ilustracją do slajdu; to ścieżka, dzięki której recenzent może zlokalizować słabe ogniwo.

Twierdzenie powinno również określać, czego nie próbuje dowodzić. Argumentacja może wspierać bezpieczne użycie w jednym zadaniu, nie dowodząc ogólnej inteligencji, uniwersalnej uczciwości ani przydatności dla każdej populacji. Może wspierać wdrożenie w określonym modelu operacyjnym, nie dowodząc, że niezarejestrowana konfiguracja będzie działać w ten sam sposób. Zaprzeczenia nie są ozdobnikami skromności. Zapobiegają rozprzestrzenianiu się wąskiego wyniku w organizacji jako znacznie szerszej obietnicy.

Za tą precyzją stoi pożyteczna europejska intuicja. Rozporządzenie 402/2013 wymaga, aby wnioskodawca kolejowy zdecydował, czy zmiana jest znacząca, wybrał zasadę akceptacji ryzyka i, w stosownych przypadkach, skorzystał z niezależnej oceny. Wnioskodawca nie musi udowadniać, że każdy możliwy przyszły stan kolei jest bezpieczny. Ma za zadanie uczynić bieżącą zmianę i jej interfejsy na tyle zrozumiałymi, aby możliwa była proporcjonalna decyzja. Zespoły AI mogą przyjąć tę samą dyscyplinę. Nazwij zmianę, nazwij kontekst operacyjny i uczyń granicę widoczną.

Zagrożenia to warunki, nie nagłówki

Zagrożenie to warunek, który może prowadzić do szkody. To rozróżnienie jest bardziej użyteczne, niż się wydaje. Błędna decyzja o przyznaniu świadczenia to skutek. Zagrożeniem może być niekompletny rekord połączony z systemem, który przedstawia niepoparte zalecenie jako gotowe do zatwierdzenia. Opóźnione ostrzeżenie o awarii to skutek. Zagrożeniem może być nieaktualny strumień danych z czujnika, który przepływ pracy traktuje jako bieżący. Naruszenie prywatności to skutek. Zagrożeniem mogą być zbyt szerokie uprawnienia do wyszukiwania połączone z narzędziem kopiującym materiał źródłowy do trwałego rekordu.

Opisywanie zagrożeń w ten sposób przesuwa uwagę na wcześniejszy etap. Umożliwia projektowanie mechanizmów kontroli i kontroli operacyjnej. Jeśli zagrożeniem jest niepoparte zalecenie przedstawione z nadmierną powagą, mechanizm kontroli może wymagać dowodów źródłowych, ujawniać niepewność, ograniczać działanie i zapewniać ścieżkę przeglądu. Jeśli zagrożeniem są nieaktualne dane wejściowe, mechanizm kontroli może sprawdzać świeżość, oznaczać stan danych, blokować działanie lub kierować je do człowieka. Jeśli zagrożeniem jest nadmierny dostęp, mechanizm kontroli może ograniczać wyszukiwanie, rozdzielać tożsamości, usuwać dane z wyników i rejestrować decyzję o dostępie. Mechanizm kontroli powinien dotyczyć warunku, a nie tylko obiecywać ostrożność wokół skutku.

Analiza zagrożeń powinna obejmować przewidywalne niewłaściwe użycie, nie tylko cel zapisany w dokumencie zamówieniowym. Akt o sztucznej inteligencji czyni to wyraźnym w przypadku systemów wysokiego ryzyka. Artykuł 9 wymaga oceny ryzyka, gdy system jest używany zgodnie z przeznaczeniem oraz w warunkach racjonalnie przewidywalnego niewłaściwego użycia. Niewłaściwe użycie nie oznacza każdej absurdalnej prośby. Oznacza użycia, które kompetentny zespół mógłby przewidzieć na podstawie interfejsu, zachęt, instrukcji i otaczającego przepływu pracy. Jeśli najszybsza ścieżka w systemie polega na zaakceptowaniu zalecenia bez czytania jego dowodów, ta ścieżka należy do analizy, nawet jeśli polityka wymaga przeglądu.

Zagrożenia żyją także na styku systemów. Model może wydać zalecenie o ograniczonym zakresie, ale integracja może przekształcić je w instrukcję bez ograniczeń. Dostawca może udostępnić punkt końcowy z wersjonowaniem, ale wdrożenie może buforować odpowiedzi po upływie okresu ważności. Organ publiczny może zachować odpowiedzialność decyzyjną, ale umowa może uczynić dostawcę jedyną stroną uprawnioną do wglądu w ślad audytowy. Granica systemu dla argumentu bezpieczeństwa musi przebiegać wzdłuż ścieżki przyczynowej aż do skutku. Zakreślenie granicy wyłącznie wokół modelu to skuteczny sposób na przeoczenie pracy, która sprawia, że model ma znaczenie.

Nie każde zagrożenie zasługuje na takie samo traktowanie. Część można ograniczyć na etapie projektowania. Część wymaga kontroli proceduralnych lub przeglądu przez człowieka. Część można monitorować i akceptować pod warunkami. Część wskazuje, że proponowane zastosowanie nie jest właściwe. Argument bezpieczeństwa powinien pokazywać rozumowanie, a nie ukrywać je za uniwersalnym wskaźnikiem ryzyka. Europejska metoda kolejowa dopuszcza różne zasady akceptacji ryzyka, w tym kodeksy praktyki, porównanie z podobnymi częściami systemu oraz jawne szacowanie ryzyka. Wniosek nie jest taki, że jedna metoda sprawdza się wszędzie. Wniosek jest taki, że metoda i jej dopasowanie do zmiany muszą być udokumentowane.

Założenia są elementami nośnymi

Każdy argument bezpieczeństwa opiera się na założeniach. Operator jest przeszkolony. Źródło jest aktualne. Próg znaczy to, co zespół myśli, że znaczy. Osoba otrzymująca alert może zadziałać na czas. Usługa zewnętrzna będzie dostępna albo istnieje rozwiązanie zastępcze. Wynik pozostanie zaleceniem, a nie stanie się decyzją w praktyce. Organizacja zauważy, jeśli aktualizacja modelu zmieni zachowanie. Wiele awarii bezpieczeństwa nie wynika z tego, że założenie było nierozsądne. Wynika z tego, że założenie było niewidoczne.

Założenie należy umieścić w argumencie wraz z właścicielem i sposobem jego weryfikacji. Jeśli argument opiera się na przeszkolonych recenzentach, argument powinien określać wymagane kompetencje, sposób ich potwierdzenia oraz co się dzieje, gdy zmienia się obsada. Jeśli argument opiera się na tym, że źródło pozostaje w oknie świeżości, system powinien rejestrować świeżość i w razie potrzeby uzależniać od niej działanie. Jeśli argument opiera się na tym, że integracja zachowuje pole, umowa interfejsu i test powinny uczynić tę zależność widoczną. Założenie, którego nie można sprawdzić, to ryzyko w łagodniejszej nazwie.

Założenia mogą dotyczyć świata zewnętrznego, a nie tylko oprogramowania. Szpital może zależeć od ścieżki klinicznej. Operator kolejowy może zależeć od interfejsu sterowania ruchem. Organ publiczny może zależeć od procesu ustawowego i zachowania władzy przez człowieka podejmującego decyzję. Producent może zależeć od wykonania przeglądów w określonym przedziale czasu. Argument bezpieczeństwa nie kontroluje każdego warunku zewnętrznego. Musi jednak wskazać, które warunki zakłada, która strona jest ich właścicielem i jak rozpoznaje się zmianę.

Gdy założenia się zmieniają, argument nie powinien po cichu się rozciągać. Zespół może zacząć od zastosowania wyłącznie rekomendacyjnego, a potem dodać automatyczne przekazanie, ponieważ zalecenie było często akceptowane. Model się nie zmienił, ale zmieniły się władza i zagrożenie. Dostawca danych może dodać nową kategorię, która wydaje się nieszkodliwa, dopóki nie zmieni znaczenia reguły na dalszym etapie. Wdrożenie może przejść z wyspecjalizowanych specjalistów do ogólnego zespołu wsparcia. To są zmiany argumentu, nawet jeśli numer wersji modelu pozostaje ten sam.

Założenia są szczególnie ważne w systemach probabilistycznych, ponieważ stabilna średnia może ukrywać niestabilną krawędź. Argument powinien wskazywać, gdzie system ma być niepewny, jakie dowody sygnalizują tę niepewność oraz który mechanizm ludzki lub techniczny przejmuje kontrolę. Celem nie jest udawanie, że niepewność można wyeliminować. Celem jest powstrzymanie niewypowiedzianego oczekiwania pewności przed staniem się polityką operacyjną.

Dowody to nie przepustka do każdego kontekstu. To założenia określają, gdzie mogą się przydać.

Dowody wymagają łańcucha nadzoru

Dowody w przypadku bezpieczeństwa to coś więcej niż wynik wpisany do tabeli. Mają swoją tożsamość, zakres, datę, metodę, osobę lub zespół odpowiedzialny oraz związek z twierdzeniem, które wspierają. Test wymaga zdefiniowanych danych wejściowych i konfiguracji. Przegląd wymaga pytania i decyzji. Ćwiczenie wymaga oczekiwanej reakcji i obserwacji. Dziennik wymaga wystarczającego kontekstu, aby można go było interpretować bez polegania na pamięci. Rekord źródłowy wymaga śladu pochodzenia. Szczegóły różnią się w zależności od dziedziny, ale zasada pozostaje stała: dowody powinny dać się zbadać po spotkaniu, na którym brzmiały przekonująco.

Akt o sztucznej inteligencji nadaje tej zasadzie moc prawną w przypadku systemów wysokiego ryzyka. Artykuł 11 wymaga, aby dokumentacja techniczna była dostępna przed wprowadzeniem systemu na rynek i na bieżąco aktualizowana. Artykuł 12 wymaga automatycznego rejestrowania istotnych zdarzeń przez cały okres użytkowania systemu, z możliwościami logowania proporcjonalnymi do zamierzonego celu i przydatnymi do identyfikacji ryzyka, wspierania monitorowania po wprowadzeniu do obrotu oraz monitorowania działania. Artykuł 13 wymaga informacji, które pozwalają wdrożeniowcom zrozumieć możliwości, ograniczenia, przewidywalne ryzyka, nadzór człowieka i wymagania dotyczące danych wejściowych. Argumentacja bezpieczeństwa łączy te zapisy zamiast pozostawiać je w osobnych szufladach zgodności.

Dowody muszą zachowywać swoje warunki. Wynik wydajności bez populacji testowej może zostać błędnie odczytany. Wynik odporności bez zastosowanych zaburzeń może zostać przeszacowany. Przegląd czynnika ludzkiego bez przepływu pracy i presji czasu, w jakich został przeprowadzony, może stać się ogólnym komplementem. Dziennik incydentów bez wersji, stanu danych i uprawnień obowiązujących w danym momencie może prowadzić do atrakcyjnej, ale błędnej przyczyny źródłowej. Im bardziej doniosła decyzja, tym mniej akceptowalne jest oddzielenie wyniku od okoliczności, które go umożliwiły.

Dowody mogą być jakościowe lub ilościowe. Udokumentowana ocena ekspercka może być ważnym dowodem, gdy pytanie jest właściwe, wiedza specjalistyczna jest zidentyfikowana, a rozumowanie jest zapisane. Wynik liczbowy może być słabym dowodem, gdy mianownik, próg lub warunki testu są niejasne. Nie ma hierarchii moralnej, w której liczba automatycznie przewyższa staranną obserwację. Argumentacja powinna wyjaśniać przydatność do celu i niepewność, a nie okazywać czci dla miejsc po przecinku.

Śledzenie pochodzenia informacji sprawia też, że spór bywa produktywny. Osoba dokonująca przeglądu powinna móc wskazać, które twierdzenie nie jest poparte dowodami, które założenie jest zbyt optymistyczne albo która kontrola nie została przeprowadzona. Dokumentacja staje się wtedy wspólnym przedmiotem dyskusji, a nie pakietem do ceremonialnego zatwierdzenia. To jeden z powodów, dla których branże związane z bezpieczeństwem inwestują w niezależną ocenę i ustrukturyzowane raporty z zapewnienia jakości. Celem nie jest stworzenie komfortu dla odmiennego zdania. Chodzi o to, aby można było precyzyjnie wskazać, gdzie leży spór.

Ryzyko rezydualne to decyzja, nie reszta

Ryzyko nie znika dlatego, że dodano kontrole. Ryzyko pozostające po zastosowaniu kontroli to ryzyko rezydualne. Musi ono zostać opisane i zaakceptowane przez organ, który jest w stanie zrozumieć dowody, nałożyć warunki i wstrzymać użytkowanie, gdy warunki nie są spełnione. Nazwanie ryzyka akceptowalnym to nie to samo co stwierdzenie, że jest ono małe. Oznacza to, że organizacja podjęła przemyślaną decyzję co do pozostałej ekspozycji w określonym kontekście i nie ukryła podstaw tej decyzji.

Artykuł 9 aktu w sprawie sztucznej inteligencji używa tego języka wprost w odniesieniu do systemów wysokiego ryzyka. Istotne ryzyko rezydualne związane z każdym zagrożeniem oraz ogólne ryzyko rezydualne muszą zostać uznane za akceptowalne. Rozporządzenie wymaga też eliminacji lub ograniczenia ryzyka, gdy jest to technicznie wykonalne, oraz środków łagodzących i kontrolnych, gdy ryzyka nie można wyeliminować. To użyteczna kolejność. Najpierw zmień projekt, jeśli to możliwe. Potem dodaj kontrole. Na koniec udokumentuj, co pozostaje. Etykieta ostrzegawcza nie jest usprawiedliwieniem dla utrzymywania możliwego do uniknięcia zagrożenia w architekturze.

Ryzyko rezydualne powinno uwzględniać odwracalność. Kryteria ryzyka w akcie w sprawie sztucznej inteligencji uwzględniają to, czy skutek można skorygować lub odwrócić, i zauważają, że niekorzystne skutki dla zdrowia, bezpieczeństwa lub praw podstawowych nie powinny być traktowane jako łatwo odwracalne tylko dlatego, że istnieje techniczny przycisk cofania. To ciche, ale ważne rozróżnienie. Projekt można poprawić. Utratę świadczenia, odmowę usługi czy publiczne oskarżenie może być znacznie trudniej naprawić. Dokumentacja powinna przypisywać silniejsze kontrole tam, gdzie osoba, której dotyczy skutek, nie może w praktyce zrezygnować ani cofnąć wyniku.

Akceptacja musi mieć warunki. System może zostać zaakceptowany dla ograniczonego pilotażu, przeszkolonego zespołu, wskazanego źródła danych i ścieżki przeglądu. Nie może zostać zaakceptowany dla innej populacji, przepływu pracy bez nadzoru ani integracji, która usuwa dowody. Warunki powinny być sformułowane tak, aby operator mógł stwierdzić, czy nadal obowiązują. Jeśli warunkiem jest jedynie to, że użytkownicy będą wykazywać się osądem, dokumentacja nie wyjaśnia, w jaki sposób system wspiera ten osąd ani co się dzieje, gdy obciążenie pracą utrudnia jego stosowanie.

Decyzja o ryzyku rezydualnym wymaga też terminu wygaśnięcia lub zdarzenia wyzwalającego przegląd. Stała data w kalendarzu może pomóc, ale zwykle bardziej informacyjne są zdarzenia: zmiana modelu, nowe źródło, istotny incydent, sygnał dryfu, zmiana użytkowników, nowy obowiązek prawny lub niepowodzenie ćwiczenia kontroli. Decyzja nie jest amuletem umieszczonym na wydaniu. To uprawnienie z harmonogramem utrzymania.

Nadzór człowieka musi mieć władzę

Nadzór człowieka jest często przywoływany tak, jakby sama obecność osoby gdzieś w pobliżu wyniku czyniła system bezpiecznym. Akt w sprawie sztucznej inteligencji jest bardziej wymagający. Artykuł 14 stanowi, że systemy wysokiego ryzyka muszą być zaprojektowane tak, aby osoby fizyczne mogły skutecznie je nadzorować podczas użytkowania. Nadzór musi być proporcjonalny do ryzyka, autonomii i kontekstu. Osoby wyznaczone do nadzoru powinny rozumieć możliwości i ograniczenia, wykrywać anomalie, rozpoznawać błąd automatyzacji, interpretować wyniki, decydować o nieużywaniu lub nadpisaniu oraz interweniować lub zatrzymać system w ramach bezpiecznej procedury.

To są wymagania projektowe w takim samym stopniu, jak wymagania kadrowe. Recenzent nie może zinterpretować wyniku, jeśli dowody są ukryte. Recenzent nie może zakwestionować zalecenia, jeśli interfejs przedstawia akceptację jako jedyną wygodną drogę. Recenzent nie może zatrzymać systemu, jeśli zatrzymanie wymaga uprawnień, których nikt nie nadał. Recenzent nie może sprawować sensownego nadzoru, jeśli jest oceniany wyłącznie przez pryzmat przepustowości. Analiza bezpieczeństwa powinna zatem traktować rolę człowieka jako element sterujący z danymi wejściowymi, uprawnieniami, obciążeniem pracą, szkoleniem i obserwowalnym zachowaniem.

Uprawnienia to szczegół, który uprzejme opisy pomijają. Kto może wstrzymać przepływ pracy. Kto może cofnąć działanie. Kto może stwierdzić, że założenie przestało obowiązywać. Kto może skontaktować się z dostawcą. Kto jest właścicielem rejestru. Kto decyduje, czy ryzyko szczątkowe jest nadal akceptowalne. Jeśli nikt nie ma tych uprawnień, opis „człowiek w pętli” jest fikcją. Osoba może widzieć wynik, ale widzenie nie jest zarządzaniem.

Dobry nadzór jest też selektywny. Celem nie jest wysyłanie każdego błahego szkicu do komisji. Chodzi o to, by ludzki osąd pojawiał się tam, gdzie wymagają tego konsekwencje, niepewność lub sporność. Niektóre przypadki można obsłużyć za pomocą ustrukturyzowanych kontroli. Niektóre wymagają wyszkolonego specjalisty. Niektóre wymagają dwóch niezależnych potwierdzeń zgodnie z obowiązującym prawem. Niektóre należy odrzucić. Analiza powinna wyjaśniać ten dobór i wykazać, że wybrana droga jest dostępna w rzeczywistym działaniu, a nie tylko w podręczniku procedur.

Jest w tym pewien rodzaj skromnego szacunku. Przyjmuje on, że ludzie się męczą, że kolejki rosną, że interfejsy kształtują uwagę i że ostrzeżenie, które pojawia się sto razy, może przestać być ostrzeżeniem. Inżynieria bezpieczeństwa nauczyła się tego przez doświadczenie w transporcie i przemyśle. Zespoły AI nie muszą powtarzać każdej lekcji, przeprowadzając możliwy do uniknięcia eksperyment na społeczeństwie.

Zmiany wciąż wkraczają do analizy

Analiza bezpieczeństwa jest żywa, ponieważ system jest żywy. Wersja modelu może się zmienić, ale równie dobrze mogą się zmienić prompt, indeks wyszukiwania, taksonomia, polityka, sprzęt, kadry, interfejs, źródło danych lub dostawca. Drobna zmiana może unieważnić założenie lub przesunąć element sterujący. Wynikające z tego ryzyko może być wyższe, niższe lub po prostu inne. Właściwą reakcją nie jest zamrożenie systemu na zawsze. Chodzi o to, by uczynić zmianę widoczną, sklasyfikować jej znaczenie i zdecydować, które części argumentacji należy ponownie przeanalizować.

Praktyka kolejowa daje jasny wzorzec. Rozporządzenie 402/2013 stosuje wspólną metodę, gdy zmiany techniczne, operacyjne lub organizacyjne wpływają na system kolejowy. Wnioskodawca rozważa znaczenie zmiany i, gdy to konieczne, stosuje zasady akceptacji ryzyka oraz niezależną ocenę. Rozporządzenie ostrzega również, że suma zmian od ostatniego procesu oceny ryzyka może mieć znaczenie. Kilka małych zmian może złożyć się na jedną znaczącą. Nadzór nad AI potrzebuje tej samej podejrzliwości wobec nieszkodliwie wyglądających przyrostów.

W przypadku AI rejestr zmian powinien wskazywać, co się zmieniło, a co nie. Czy zmieniły się wagi modelu. Czy zmieniło się gromadzenie dowodów. Czy zmieniły się uprawnienia narzędzi. Czy zmieniła się populacja użytkowników. Czy próg się przesunął. Czy przepływ pracy stał się automatyczny w punkcie, który wcześniej był jedynie doradczy. Czy ścieżka awaryjna pozostała dostępna. Czy ocena uwzględniła nowy stan. Rejestr powinien powiązać każdą odpowiedź z danym twierdzeniem, zagrożeniem, elementem sterującym lub założeniem oraz określić testy lub przeglądy wymagane przed wdrożeniem.

Kontrola zmian powinna obejmować bezpieczny tryb wdrażania. Uruchomienie testowe w tle, stopniowe wdrażanie, ograniczona populacja, jawny warunek wycofania lub potwierdzenie przez człowieka mogą powstrzymać nowe zachowanie przed staniem się faktem w skali całej instytucji, zanim ktokolwiek je sprawdzi. Te mechanizmy nie są dowodem na słabość systemu. Są dowodem na to, że organizacja rozumie, iż nowe zachowanie potrzebuje miejsca, by się uczyć.

Monitorowanie po wprowadzeniu do obrotu rozszerza analizę przypadku na okres po wydaniu produktu. Artykuł 9 odsyła do danych gromadzonych na podstawie artykułu 72, a artykuł 72 wymaga udokumentowanego systemu monitorowania systemów wysokiego ryzyka przez cały okres ich użytkowania. Monitorowanie powinno wyłapywać sygnały istotne dla zgłaszanego roszczenia: zmienione wzorce błędów, nietypowe odmowy, nieprzewidziane zastosowania, wyniki odwołań, brakujące dowody, zdarzenia bezpieczeństwa oraz awarie nadzoru ludzkiego. Pulpit, który raportuje wyłącznie dostępność systemu, to przyjemny sposób na przeoczenie problemu z bezpieczeństwem.

Niezależna ocena to pożyteczna niedogodność

Osoby, które zbudowały system, znają jego elegancję, skróty i presję, pod jaką powstał. Ta wiedza jest konieczna. Nie wystarcza jednak do zaakceptowania ryzyka. Niezależna ocena stwarza przestrzeń dla kogoś, kto może zakwestionować argumentację, nie dzieląc tych samych motywacji związanych z wdrożeniem. Niezależność nie wymaga wrogości ani zewnętrznego logo na każdej stronie. Wymaga kompetencji, zakresu działania, dostępu do dowodów oraz uprawnień do odnotowania sprzeciwu, którego właściciel nie może po prostu usunąć.

Europejska metoda kolejowa nadaje temu rozdzieleniu konkretny kształt. ERA opisuje jednostkę oceniającą odpowiedzialną za sprawdzenie prawidłowego stosowania procesu oceny ryzyka i jego wyników, z wymogami dotyczącymi kompetencji, akredytacji lub uznania. Rozporządzenie dopuszcza niezależny i kompetentny podmiot zewnętrzny lub wewnętrzny, pod warunkiem spełnienia kryteriów. To rozwiązanie jest proporcjonalne, a nie teatralne. Uznaje, że zapewnienie jakości może pochodzić z wewnątrz, gdy niezależność jest rzeczywista, oraz że odznaka nie uratuje recenzenta, który nie widzi istotnych dowodów.

W przypadku sztucznej inteligencji niezależność może być warstwowa. Właściciel domeny sprawdza, czy zastosowanie jest zgodne z prawem i czy analiza zagrożeń odzwierciedla rzeczywistą pracę. Recenzent inżynieryjny sprawdza integrację i tryby awarii. Recenzent ds. bezpieczeństwa testuje ścieżki dostępu i manipulacji. Recenzent operacyjny sprawdza obciążenie pracą, eskalację i odzyskiwanie. Funkcja nadzoru lub zgodności sprawdza dokumentację i obowiązki. W przypadku zastosowań o poważnych konsekwencjach może mieć zastosowanie ocena zewnętrzna lub ścieżka jednostki notyfikowanej na podstawie odpowiednich ram prawnych. Dokumentacja bezpieczeństwa powinna określać rolę każdego recenzenta i pytania, które może on zadawać.

Niezależność stanowi również ochronę przed nieprzejrzystością dostawcy. Raport dostawcy może wspierać roszczenie, ale wdrażający musi wiedzieć, co było testowane, w jakiej konfiguracji i jakie ograniczenia pozostają. Jeśli kluczowego wyniku nie można odtworzyć, sprawdzić ani przenieść po zakończeniu umowy, ta zależność musi znaleźć się w dokumentacji. Zamówienia powinny wymagać dostępu do dowodów, identyfikacji wersji, powiadamiania o incydentach, informowania o zmianach, eksportu, wycofania i praktycznego wyjścia z umowy. Słowo „praktyczny” robi tu ciężką pracę. Prawo, którego nie można wykonać pod presją czasu, nie jest w istocie żadną kontrolą.

Dobra ocena daje więcej niż pieczątkę zatwierdzenia. Odnotowuje warunki, otwarte ustalenia, luki w dowodach, ryzyko rezydualne i wymagane działania następcze. Czasem właściwą decyzją jest wydanie produktu z ograniczeniami. Czasem opóźnienie. Czasem odrzucenie proponowanego zastosowania. Kultura bezpieczeństwa to nie taka, w której każdy przypadek przechodzi. To taka, w której decyzja wynika z argumentacji.

Co akt o sztucznej inteligencji wnosi do argumentacji

Akt o sztucznej inteligencji nie zamienia każdego wdrożenia sztucznej inteligencji w kolej. Ustanawia jednak europejski język dla zarządzania ryzykiem, dokumentacji technicznej, rejestrowania, przejrzystości, nadzoru ludzkiego, dokładności, odporności i cyberbezpieczeństwa systemów wysokiego ryzyka. Dokumentacja bezpieczeństwa może pomóc organizacji połączyć te obowiązki w spójne wyjaśnienie operacyjne, zamiast traktować każdy artykuł jako osobne zadanie zgodności.

Artykuł 8 wiąże zgodność z zamierzonym przeznaczeniem i ogólnie uznawanym stanem techniki oraz umożliwia włączenie niezbędnych badań, sprawozdań, informacji i dokumentacji do istniejących unijnych procedur harmonizacyjnych, jeśli produkt jest już nimi objęty. Ma to znaczenie dla inżynierii bezpieczeństwa. Uznaje, że system może już mieć dojrzały proces zapewniania zgodności i że powielanie plików jest mniej przydatne niż ich powiązanie. Przypadek powinien pokazywać, gdzie w szerszym argumencie dotyczącym produktu lub usługi znajdują się dowody dotyczące AI.

Artykuł 11 i załącznik IV nadają dokumentacji technicznej szeroki zakres. Obejmuje ona zamierzone przeznaczenie, wersje, interfejsy, sprzęt, metody opracowywania, architekturę, pochodzenie i charakterystykę danych, nadzór człowieka, z góry określone zmiany, procedury walidacji i testowania, wskaźniki, dzienniki testów oraz środki cyberbezpieczeństwa. Nie jest to to samo co argument bezpieczeństwa, ale dostarcza wielu elementów, których taki argument potrzebuje. Zespół może przypisać każdy element do konkretnego twierdzenia i ujawnić, co wciąż nie ma właściciela ani dowodów.

Wymóg prowadzenia dzienników z artykułu 12 jest szczególnie praktyczny. Jeśli system wysokiego ryzyka musi technicznie umożliwiać automatyczne rejestrowanie zdarzeń przez cały okres jego użytkowania, decyzja o wydaniu powinna uwzględniać, co system faktycznie może odtworzyć. Które dane wejściowe, model, konfigurację, dowody, wywołania narzędzi, interwencje człowieka i działania następcze można ze sobą powiązać. Które dzienniki są pod kontrolą dostawcy, a które pod kontrolą wdrażającego. Jak są chronione i przechowywane. Czy osoba, której dane dotyczą, lub organ może zrozumieć istotną ścieżkę bez otrzymania wyciągu z niepowiązanych danych osobowych.

Artykuł 15 dodaje perspektywę cyklu życia dla dokładności, odporności i cyberbezpieczeństwa, w tym odporność na błędy, usterki i niespójności oraz, w stosownych przypadkach, plany tworzenia kopii zapasowych lub rozwiązań awaryjnych. Argument bezpieczeństwa daje tym pojęciom konkretne miejsce. Twierdzenie nie polega na tym, że wynik jest wysoki. Twierdzenie polega na tym, że system działa spójnie zgodnie z zamierzonym przeznaczeniem, że znane warunki awarii są ograniczone oraz że proces pracy ma bezpieczną reakcję, gdy one wystąpią. Dowody muszą określać warunki, w jakich wniosek pozostaje aktualny.

Obowiązki wynikające z rozporządzenia stosują się w zależności od systemu, dostawcy, wdrażającego i sposobu użycia. Argument bezpieczeństwa nie powinien udawać, że ogólny szablon rozstrzyga kwestię klasyfikacji lub stanowi poradę prawną. Powinien rejestrować decyzję o zastosowaniu, jej uzasadnienie oraz punkty, które mogłyby ją zmienić. To kolejna korzyść z jawnych założeń. Gdy zmienia się jakiś fakt, organizacja wie, która część argumentu wymaga uwagi, zamiast w panice odkrywać całą mapę prawną na nowo.

Lotnictwo traktuje uczenie się jako część zapewniania zgodności

Dokument Europejskiej Agencji Bezpieczeństwa Lotniczego (EASA) „Artificial Intelligence Concept Paper Issue 2" jest przydatny, ponieważ nie opisuje bezpieczeństwa AI jako pojedynczej właściwości modelu. Dokument doprecyzowuje wytyczne dla aplikacji poziomu 1, które wspierają możliwości człowieka, oraz pogłębia prace nad zapewnianiem uczenia się, wyjaśnialnością AI i oceną opartą na etyce. Odnosi się również do systemów poziomu 2, w których AI może automatycznie podejmować decyzje pod nadzorem człowieka, i podkreśla współpracę człowieka z AI oraz projektowanie bezpiecznych interakcji.

Najważniejsza myśl nie polega na tym, że każda organizacja powinna kopiować terminologię lotniczą. Chodzi o to, że zapewnianie zgodności musi podążać za relacją między systemem a pracą człowieka. Model, który wspiera wyszkolonego operatora, nie stanowi tego samego problemu bezpieczeństwa co model, który podejmuje decyzje, podczas gdy człowiek jedynie nadzoruje. Zdolność operatora do zrozumienia, interwencji i odzyskania kontroli jest częścią systemu. Podobnie jak granice wokół uczenia się, aktualizacji i dowodów. Dokument EASA daje zespołom AI europejski przykład branży, która stara się uczynić te relacje jawnymi przed wdrożeniem.

Zapewnienie uczenia się to trafne określenie, ponieważ uczenie maszynowe może zmienić typowy sposób przedstawiania dowodów. Konwencjonalne wydanie oprogramowania można przetestować względem zdefiniowanej implementacji. System adaptacyjny może zmieniać swoje zachowanie wraz ze zmianami danych, stanu lub środowiska. Przypadek bezpieczeństwa musi zatem określać, co może się uczyć, co jest zamrożone, jak wykrywana jest zmiana, które dowody są odświeżane i kiedy system ponownie wchodzi w proces akceptacji. Jeśli uczenie się pozostaje poza przypadkiem, przypadek dotyczy systemu z wczoraj.

Współpraca człowieka z AI również zmienia znaczenie nadzoru. Człowiek nie jest hamulcem awaryjnym przymocowanym do maszyny zaprojektowanej bez kierowcy. Zespół to układ socjotechniczny z rolami, oczekiwaniami, sygnałami, uprawnieniami i szkoleniem. Bezpieczna interakcja może wymagać, aby maszyna wyjaśniła ograniczenie, poprosiła o potwierdzenie, odmówiła działania lub uwidoczniła niepewność. Może wymagać, aby człowiek kwestionował maszynę, a organizacja nagradzała takie kwestionowanie. Dowody powinny badać samą interakcję, a nie wnioskować o niej z zapisu polityki.

I znów, do przedstawienia argumentu nie potrzeba zmyślonego lotu ani wypadku. Dokument koncepcyjny agencji publicznej wystarczy, aby pokazać, że europejskie myślenie o bezpieczeństwie zmierza ku uczeniu się, interakcji z człowiekiem i zapewnieniu jako jednego problemu projektowego. Zespoły AI mogą potraktować ten materiał jako zachętę do zadania sobie pytania, czego uczy się ich własny system, co widzi operator i jakie dowody przetrwają zmianę.

Złożona bramka wydania, oznaczona jako taka

Przykład ilustracyjny, nie opis rzeczywistego zdarzenia: wyobraźmy sobie usługę publiczną rozważającą narzędzie AI, które pomaga pracownikom porządkować przychodzący materiał spraw przed podjęciem decyzji przez człowieka. Narzędzie nie jest upoważnione do rozstrzygania o kwalifikowalności, wysyłania zawiadomienia ani zamykania sprawy. Proponowane twierdzenie o bezpieczeństwie jest wąskie: przeszkolony pracownik może użyć narzędzia do przygotowania kolejki przeglądu, gdy rekord źródłowy jest kompletny, panel dowodów jest widoczny, zalecenie jest wyraźnie oznaczone jako zalecenie, a pracownik może je nadpisać, wstrzymać lub usunąć.

Pierwsza gałąź przypadku wymienia zagrożenia. Niekompletny rekord mógłby otrzymać pozornie spójny priorytet. Nieaktualny dokument polityki mógłby kształtować zalecenie. Kolejka mogłaby wywierać presję na recenzenta, aby zaakceptował kolejność bez sprawdzenia. Błąd uprawnień mógłby ujawnić materiały jednej osoby w innej sprawie. Aktualizacja dostawcy mogłaby zmienić znaczenie kategorii. Nie są to twierdzenia, że takie zdarzenie miało miejsce. To warunki, które zespół może rozsądnie przewidzieć na podstawie proponowanego projektu.

Następna gałąź wymienia mechanizmy kontrolne. Kompletność i aktualność danych wejściowych są sprawdzane przed wyświetleniem zalecenia. Dowody użyte do sugestii są widoczne obok sprawy. Działanie pozostaje szkicem, dopóki przeszkolona osoba go nie zaakceptuje lub nie zmieni. Brakujące źródło kieruje pozycję na inną ścieżkę. Uprawnienia są testowane na granicy pobierania danych, nie tylko w interfejsie użytkownika. Przepływ pracy ma kontrolę wstrzymania i ręczną ścieżkę. Zmiana wersji działa w trybie ograniczonym i można ją wycofać. Przypadek odnotowuje, dlaczego istnieje każda kontrola i które zagrożenie adresuje.

Dowody muszą następnie poddać mechanizmy kontrolne próbie. Test danych dostarcza niekompletne i nieaktualne rekordy i rejestruje wynik. Przegląd użyteczności sprawdza, czy pracownicy potrafią znaleźć dowody i zrozumieć zalecenie przy realistycznym obciążeniu pracą. Test dostępu sprawdza, czy sprawa nie może pobrać materiałów spoza swojego zakresu. Próba wydania weryfikuje działanie ścieżek wstrzymania i wycofania. Przegląd zmian potwierdza, że nowa kategoria i polityka nie unieważniają logiki kolejki. Są to hipotetyczne testy w tym przykładzie, a nie raporty z testów przeprowadzonych przez nazwaną usługę.

Decyzja jest warunkowa. Narzędzie może być używane do przygotowania kolejki w określonym zakresie. Nie może być używane do podjęcia ani przekazania decyzji merytorycznej. Warunek, że personel musi mieć uprawnienia do nadrzędności, jest przypisany do roli. Warunek, że świeżość źródła jest rejestrowana, jest monitorowany. Zmiana modelu, polityki, kontraktu danych, populacji użytkowników lub działania następcze powoduje ponowne otwarcie sprawy. Jeśli organizacja nie może udokumentować tych warunków, brama wydania pozostaje zamknięta. Ta historia jest użyteczna właśnie dlatego, że nikt nie musi udawać, że istniało konkretne miasto, zespół czy wtorek.

Mały przykład z naszego Centrum Zaufania

W Dweve nasze publiczne Centrum Zaufania dokonuje podobnego rozróżnienia w swoim rejestrze ocen. Strona z ocenami przedstawia metodę, która identyfikuje model, dokładny zestaw, konfigurację, zarejestrowany stan, dowody i decyzję recenzenta. Oddziela tożsamość oceny od zmieniającego się stanu modelu, odróżnia przygotowane pokrycie od rzeczywistego wyniku oraz opisuje odtwarzanie jako kontrakt zależny od przechwyconego artefaktu, grafu wykonania, routingu, kolejności, stanu, ograniczeń, narzędzi i dowodów. Strona stwierdza również, że na dzień 1 sierpnia 2026 r. nie istniał żaden pierwszy wynik wydania zewnętrznego, ponieważ takie wydanie nie miało miejsca.

To mały przykład, a nie dowód na to, że dla każdego zastosowania naszych systemów ukończono analizę bezpieczeństwa. Jego wartość polega na granicy. Metoda to nie wynik. Kategoria to nie ocena. Planowane wydanie to nie historyczne uruchomienie. Odtwarzalny zarejestrowany stan to nie to samo co żywy świat, w którym dowody i stan adaptacyjny uległy zmianie. Te rozróżnienia są dokładnie tym, czego analiza bezpieczeństwa potrzebuje, gdy określa, gdzie dowody mają zastosowanie, a gdzie się kończą.

Dla europejskiej firmy technologicznej publikowanie takich ograniczeń może wydawać się pozostawianiem pustej przestrzeni marketingowej. Jest to bardziej użyteczne niż wypełnianie tej przestrzeni liczbą, której nikt nie może obronić. Ta sama dyscyplina dotyczy organu publicznego, dostawcy, grupy badawczej czy wewnętrznego zespołu platformy. Należy określić, które dowody istnieją, które są przygotowane, które są chronione, które nie zostały zebrane oraz które przyszłe zdarzenie stworzyłoby nowy wynik. Czytelnik może wtedy zdecydować, co dowody potwierdzają.

Nasz przykład pokazuje również, dlaczego Centrum Zaufania należy czytać jako indeks dowodów, a nie obietnicę. Strona publiczna wskazuje na granice tożsamości, metody, przechwytywania, przeglądu i wydania. Nie usuwa to potrzeby sprawdzenia konkretnego wdrożenia, celu lub dotkniętej populacji. Analiza bezpieczeństwa dodałaby ten lokalny kontekst, zagrożenia rzeczywistego przepływu pracy oraz uprawnienia osoby podejmującej decyzję. Publiczna przejrzystość to powierzchnia startowa, a nie uniwersalny certyfikat.

Co może udowodnić analiza bezpieczeństwa

Dobra analiza bezpieczeństwa może wspierać ograniczony wniosek. Może wykazać, że system został zaprojektowany do określonego celu, że przewidywalne zagrożenia zostały zidentyfikowane, że środki kontroli odnoszą się do tych zagrożeń, że dowody zostały zebrane w określonych warunkach, że ryzyko szczątkowe zostało ocenione, że właściwy organ zaakceptował lub odrzucił użycie oraz że organizacja ma sposób na wykrywanie zmian i ponowne rozpatrzenie decyzji. Może uczynić argument wystarczająco przejrzystym do kwestionowania i utrzymania.

Może również pokazać, co jest niepewne. Analiza może wykazać mocne dowody dla jednej populacji i ograniczone dowody dla innej. Może wykazać, że system jest odporny na zdefiniowaną klasę nieprawidłowych danych wejściowych, ale nie na nieznaną klasę. Może wykazać, że człowiek może interweniować, gdy obsada i uprawnienia są zgodne z określonymi. Może wykazać, że istnieje rozwiązanie zastępcze, ale nie zostało jeszcze przetestowane w pełnej skali operacyjnej. Rzetelna analiza nie ukrywa tych asymetrii. Czyni z nich warunki użytkowania.

Safety case może również wspierać decyzje dotyczące zakupów i zarządzania. Kupujący może porównać dowody przedstawione przez dostawcę z dowodami wymaganymi przez proces. Regulator może zobaczyć, które twierdzenia są poparte, a których zapisów brakuje. Zarząd może zrozumieć, gdzie leży ryzyko rezydualne i kto jest za nie odpowiedzialny. Operator może wiedzieć, który sygnał powinien spowodować wstrzymanie pracy. Osoby, których to dotyczy, mogą mieć jaśniejszą ścieżkę do zakwestionowania wyniku. Safety case staje się mapą odpowiedzialności, a nie tylko artefaktem inżynieryjnym.

Może wspierać zmiany bez udawania, że zmiana nic nie kosztuje. Łącząc twierdzenia, zagrożenia, założenia, mechanizmy kontroli i dowody, organizacja może zidentyfikować najmniejszą sensowną ponowną ocenę, gdy zmieni się komponent. To bardziej wydajne niż ślepe powtarzanie każdego testu i bezpieczniejsze niż założenie, że ponowna ocena nie jest konieczna. Proporcjonalność działa tylko wtedy, gdy struktura jest widoczna. W przeciwnym razie zespół albo wykonuje rytuały, albo idzie na skróty.

Czego safety case nie może udowodnić

Safety case nie może udowodnić, że nigdy nie wystąpi żadna szkoda. Rzeczywiste systemy napotykają warunki, których nie przewidziano, a ludzie reagują na bodźce i presję w sposób, którego żaden diagram nie jest w stanie w pełni przewidzieć. Celem nie jest pewność. Celem jest zdyscyplinowana podstawa do działania, uczenia się i zatrzymania, gdy podstawa przestaje obowiązywać.

Nie może udowodnić, że model jest ogólnie inteligentny, ogólnie sprawiedliwy ani bezpieczny w każdej dziedzinie. Dowody mają swój zakres. Test na jednym zbiorze danych nie przesądza o działaniu na innym. Udana ocena w jednym procesie nie ustanawia tej samej wiarygodności w innym. Dobrze zaprojektowana ścieżka zatrzymania nie dowodzi, że każdy operator z niej skorzysta bez szkolenia, czasu i wsparcia organizacyjnego. Safety case musi opierać się pokusie zamiany lokalnych dowodów w globalny przymiotnik.

Nie może przenieść odpowiedzialności na dostawcę, audytora ani znak certyfikacyjny. Dowody mogą być wytworzone przez kogoś innego, ale wdrożeniowiec nadal ma zastosowanie, proces i ludzi, którzy zależą od wyniku. Umowy mogą przypisywać obowiązki i zapewniać dostęp. Nie mogą sprawić, że organizacja nie będzie świadoma systemu, który obsługuje. Certyfikat również nie usprawiedliwia zmiany, która wyprowadza system poza oceniany zakres.

Nie może uczynić zabronionego lub nieodpowiedniego zastosowania akceptowalnym przez dodanie dokumentacji. Jeśli zagrożenia nie można kontrolować na akceptowalnym poziomie, odpowiedzią może być zmiana przeznaczenia lub rezygnacja z wdrożenia. Safety case często opisuje się jako zapewnienie, ale najbardziej wartościowym wynikiem może być dobrze uzasadnione „nie”. Kompletny plik może nadal wspierać złą decyzję, jeśli argumentacja jest słaba. Celem pliku jest poprawa decyzji, a nie tylko uczynienie jej bardziej czytelną po jej podjęciu.

Wreszcie nie może zastąpić prawa, profesjonalnego osądu ani odpowiedzialności demokratycznej. Jest instrumentem inżynieryjnym i zarządczym. Powinien pomagać ludziom zrozumieć decyzję i jej warunki, a nie udawać, że rozstrzyga kwestie należące do sądów, organów regulacyjnych, klinicystów, urzędników publicznych ani osób, których dotyczy.

Pytania na europejskie spotkanie wydawnicze

Zespół nie musi czekać na doskonały standard ani 400-stronicowy segregator, aby zacząć. Może zadać serię prostych pytań. Co dokładnie twierdzimy, że ten system może robić. Kogo dotyczy sytuacja, gdy zawiedzie. Które zagrożenia są warunkami w systemie i procesie, a nie niejasnymi złymi skutkami. Które założenia muszą pozostać prawdziwe. Jakie dowody wspierają każde twierdzenie i w jakiej konfiguracji oraz dla jakiej populacji. Co pozostaje niepewne. Kto akceptuje ryzyko rezydualne. Kto może zatrzymać system. Jakie zdarzenie ponownie otworzyłoby argumentację.

Spotkanie powinno zrobić miejsce na mniej wygodne pytanie: co sprawiłoby, że odmówilibyśmy wydania. Jeśli jedyną odpowiedzią jest niższy wynik, zespół prawdopodobnie nie opisał swoich zagrożeń. Odmowa może być wywołana przez brakujące dowody, nieprzypisane założenie, nieudane ćwiczenie odzyskiwania, niedostępnego recenzenta, nieograniczoną integrację lub zmianę, której nie można odtworzyć. Nazwanie warunków odmowy zamienia bezpieczeństwo w kontrolę operacyjną, a nie w nastrój.

Zapytaj, jak sprawa podróżuje wraz z systemem. Czy operator może znaleźć zamierzony cel, ograniczenia i drogę zatrzymania. Czy osoba badająca incydent może zidentyfikować model, dowody, uprawnienia i decyzje ludzkie, które miały znaczenie. Czy nabywca może wyeksportować zapisy, jeśli dostawca się zmieni. Czy organ regulacyjny może uzyskać informacje potrzebne do oceny zgodności. Czy nowy zespół może zrozumieć, dlaczego istnieje kontrola, bez przeprowadzania rozmowy z osobą, która odeszła. Sprawa bezpieczeństwa, która żyje tylko w prywatnym folderze, jest kruchą pamięcią, a nie żywym argumentem.

Zapytaj, jak zmienia się sprawa. Jaki jest wyzwalacz przeglądu dla aktualizacji modelu, zmiany źródła, zmiany polityki, nowej grupy użytkowników, nowego narzędzia, nowej jurysdykcji lub nowego działania downstream. Które oceny są powtarzane, a które założenia są sprawdzane. Co się dzieje, gdy monitoring wykryje słaby sygnał, ale jeszcze nie poważny incydent. Czy istnieje bezpieczna, przypisana droga do wstrzymania i zbadania. Dobrze zarządzana organizacja powinna być w stanie odpowiedzieć bez wymyślania kryzysu, aby proces wydawał się realny.

I zapytaj, czy dowody mogą być odczytane przez ludzi, których decyzję mają wspierać. Dokument techniczny, którego nikt nie potrafi zinterpretować, nie jest przejrzysty. Polityka, której nikt nie potrafi zastosować, nie jest kontrolą. Pulpit pełen zielonych komórek, który ukrywa mianownik, nie jest zapewnieniem. Europejska praktyka bezpieczeństwa jest najlepsza, gdy udostępnia rozumowanie osobie ponoszącej odpowiedzialność, a nie tylko osobie, która skompletowała dokument.

Cicha przewaga uczciwego argumentu

Sprawy bezpieczeństwa z daleka wyglądają na biurokratyczne, ponieważ zawierają zapisy, role, warunki i punkty przeglądu. Z bliska są sposobem na utrzymanie uczciwości inżynierii, gdy systemy stają się przekonujące. Zapobiegają temu, aby test udawał decyzję, założenie udawało fakt, planowana ocena udawała wynik, a obecność człowieka udawała autorytet.

Europa ma już elementy tej dyscypliny w swoich instytucjach. Koleje traktują zmiany techniczne, operacyjne i organizacyjne jako kwestię ryzyka i stosują wspólne metody oraz niezależną ocenę. Wytyczne lotnicze omawiają zapewnienie uczenia się, wyjaśnialność i współpracę człowieka z AI. Akt w sprawie sztucznej inteligencji łączy zarządzanie ryzykiem w cyklu życia z dokumentacją, logami, przejrzystością, nadzorem ludzkim i wydajnością w cyklu życia. To nie są identyczne ramy i nie powinny być spłaszczone do jednej listy kontrolnej. Łączy je jednak szacunek dla warunków, dowodów i odpowiedzialności.

Praktyczna lekcja jest na tyle prosta, że można ją zabrać na poniedziałkowe spotkanie. Zacznij od twierdzenia, które ma krawędzie. Nazwij zagrożenia, które mogłyby je unieważnić. Zapisz założenia, które pozwalają mu się utrzymać. Umieść kontrole tam, gdzie faktycznie odbywa się praca. Dołącz dowody z tożsamością i zakresem. Oceń ryzyko rezydualne, zamiast je ukrywać. Daj osobie realną władzę do interwencji. Otwórz ponownie argument, gdy zmieni się system lub kontekst. Pozwól niezależnemu recenzentowi być niewygodnym. Publikuj ograniczenia z taką samą starannością jak sukcesy.

To podejście nie uczyni każdego systemu AI bezpiecznym i nie zamieni niepewności w pewność. Utrudni utrzymanie niebezpiecznej pewności siebie. Da operatorom drogę do wstrzymania, recenzentom konkretny materiał do zakwestionowania, a osobom dotkniętym lepsze wyjaśnienie, gdzie leży odpowiedzialność. Ułatwi też ulepszanie dobrych systemów, ponieważ organizacja będzie mogła zobaczyć, która część argumentu się zmieniła.

Bezpieczeństwo nie jest zatem ostatnim akapitem po zakończeniu prac inżynieryjnych. To nić, która spaja cel, projekt, ludzi, dowody i zmiany. Europa może uczyć się od safety cases, ponieważ oferują one obywatelską wersję dyscypliny inżynieryjnej: żaden slogan nie jest akceptowany bez ścieżki, żadna ścieżka nie jest akceptowana bez dowodów, a żadne dowody nie mogą wykraczać poza swoje założenia.

Źródła