System wysokiego ryzyka to nie model wysokiego ryzyka

Risk nie mieszka w modelu jak etykieta ostrzegawcza. Wyłania się z zamierzonego przeznaczenia, wdrożenia, autorytetu, interfejsów oraz ludzi, którzy muszą...

System wysokiego ryzyka to nie model wysokiego ryzyka

Etykieta jest przypisana do zastosowania, a nie do pudełka

Model można skopiować z jednego serwera na drugi bez uczenia się czegokolwiek. Jego wagi, kod i reklamowane możliwości mogą pozostać niezmienione. Jednak pytanie, które Europa zadaje w związku z rzeczą wokół modelu, może zmienić się całkowicie. Do czego on służy? Kto go używa? Czyją pozycję może zmienić? Który zapis trafia do przepływu pracy? Kto może zakwestionować odpowiedź, poprawić ją, zatrzymać ją lub później odkryć, dlaczego została zastosowana?

Nie jest to próba uczynienia prostego tematu bardziej doniosłym, niż jest. To zwykła różnica między komponentem a systemem. Tarcza hamulcowa nie jest pojazdem drogowym. Formuła arkusza kalkulacyjnego nie jest decyzją podatkową. Model AI ogólnego przeznaczenia nie jest sam w sobie każdym systemem AI, który może zostać wokół niego zbudowany w przyszłości. Nad tą różnicą łatwo skinąć głową i niezwykle łatwo ją zgubić, gdy spotkanie dotyczące zakupów zaczyna mówić o modelu tak, jakby zawierał już całe przyszłe wdrożenie.

Akt w sprawie sztucznej inteligencji Unii Europejskiej utrzymuje tę różnicę w polu widzenia. Definiuje system AI i oddzielnie definiuje model AI ogólnego przeznaczenia. Jego zasady dotyczące wysokiego ryzyka odnoszą się do systemów AI w szczególnych okolicznościach, w tym do systemów będących elementami bezpieczeństwa regulowanych produktów oraz systemów stosowanych w wymienionych obszarach. Akt czyni również zamierzone przeznaczenie kluczowym dla klasyfikacji i dokumentacji systemu AI. Nie zachęca zespołu do wskazania nazwy modelu, przyklejenia zielonej, żółtej lub czerwonej etykiety i ogłoszenia, że praca została wykonana.

To powinno być wyzwalające, a także wymagające. Model nie nosi ze sobą stałego moralnego horoskopu. Staranna analiza może być wąska tam, gdzie zamierzone przeznaczenie jest wąskie, i może stać się poważna tam, gdzie poważne stają się władza, ekspozycja i konsekwencje. Haczyk polega na tym, że analiza musi dotyczyć rzeczywistego systemu. Nie demo. Nie prezentacji dostawcy. Nie nieszkodliwego zadania, które rozpoczęło projekt sześć miesięcy temu. Systemu, który będzie odbierał dane wejściowe, udostępniał wyniki, kształtował decyzję i będzie obsługiwany w zwykły wtorek.

Rozważmy celowo hipotetyczną ilustrację. Ten sam model językowy jest najpierw podłączony do wewnętrznego narzędzia wyszukiwania wiedzy. Wyszukuje fragmenty polityk dla przeszkolonego współpracownika, który może otworzyć oryginalne źródło i napisać własną odpowiedź. Później organizacja podłącza model do formularza przyjęcia zgłoszenia, umieszcza jego rekomendację na górze rejestru sprawy, nakłada na sprawę termin i sprawia, że zaakceptowanie rekomendacji jest najszybszym sposobem na opróżnienie kolejki. Nie potrzeba fikcyjnej rady, pacjenta, pracownika ani incydentu, aby dostrzec zmianę. Model może być identyczny. Rola wyniku, ścieżka danych, zachęta, osoba, której dotyczy sprawa, i praktyczna władza interfejsu już nie są.

To jest argument tego artykułu: system wysokiego ryzyka to nie model wysokiego ryzyka. Model może być ważną częścią systemu i może mieć własne obowiązki. Ale analiza ryzyka staje się znacząca dopiero wtedy, gdy obejmuje zamierzone przeznaczenie, kontekst wdrożenia, użytkowników, osoby, których dotyczy, i integrację w dalszej części procesu. Te szczegóły to nie dokumentacja dołączona po pracach inżynieryjnych. To okoliczności, które nadają wynikowi instytucjonalną moc.

Najedź lub wybierz warstwę. Model to jedna warstwa; konsekwencja pojawia się dopiero, gdy warstwy się spotkają.

Europa celowo używa dwóch różnych rzeczowników

Rozróżnienie zaczyna się w definicjach aktu. System AI to system oparty na maszynie, zaprojektowany do działania z różnym poziomem autonomii, który po wdrożeniu może wykazywać zdolność adaptacji i który na podstawie danych wejściowych wnioskuje, jak generować wyniki, takie jak przewidywania, treści, rekomendacje lub decyzje, mogące wpływać na środowiska fizyczne lub wirtualne. Model AI ogólnego przeznaczenia jest inny: to model AI zdolny do sprawnego wykonywania szerokiego zakresu różnych zadań, niezależnie od tego, czy jest wprowadzony na rynek, i może być zintegrowany z różnorodnymi systemami lub aplikacjami niższego szczebla.

Te definicje pokrywają się w codziennych rozmowach, ponieważ to samo słowo, AI, wykonuje ogromną ilość nieodpłatnej pracy. Nie powinny się pokrywać w ocenie. Model ogólnego przeznaczenia jest stworzony do podróżowania. Jego możliwe zastosowania są celowo szerokie. System AI to operacyjne rozwiązanie, dzięki któremu wyniki wpływają na środowisko. Ma cel, konfigurację, interfejs i otoczenie. Może obejmować model, kilka modeli, reguły deterministyczne, bazy danych, czujniki, ludzi, procedury i wiele drobnych decyzji, których nikt nie nazywa sztuczną inteligencją, dopóki nie zawiodą.

Dlatego dostawca modelu AI ogólnego przeznaczenia oraz dostawca lub wdrażający system AI nie mogą po prostu zamienić się listami kontrolnymi. Wytyczne Komisji dotyczące modeli AI ogólnego przeznaczenia mówią, że dostawcy modeli muszą udostępniać informacje i dokumentację dostawcom systemów AI niższego szczebla, aby ci dostawcy mogli zrozumieć możliwości i ograniczenia modelu oraz wypełnić własne obowiązki. To zdanie jest bardziej interesujące, niż się wydaje na pierwszy rzut oka. Zakłada, że dostawca niższego szczebla ma pracę, której dostawca modelu nie może wykonać. Dokumentacja modelu podróżuje, ale nie kończy podróży.

Jest w tym praktyczna pokora. Dostawca modelu może opisać architekturę, proces szkolenia, ocenę, zamierzone zadania, wymagania integracyjne, dane wejściowe i wyjściowe, ograniczenia i znane warunki. Zespół niższego szczebla wie, czy użytkownik jest przeszkolonym specjalistą, czy osoba, której dotyczy, może zakwestionować wynik, czy rekomendacja jest doradcza z nazwy, ale wiążąca w praktyce, czy wywołanie zewnętrznej usługi zmienia rekord i czy błędne działanie można odwrócić. Żadna ze stron nie ma pełnego obrazu samodzielnie.

Ten podział nie jest luką prawną. To mapa odpowiedzialności. Mówi, że systemem nie można zarządzać, prosząc dostawcę modelu o obietnicę kontroli nad wdrożeniem, którego nie obsługuje ani nie widzi. Mówi również, że integrator nie może zasłaniać się niewiedzą, gdy dokumentacja uwidacznia ważne ograniczenie. Nie chodzi o czyste przekazanie odpowiedzialności między podmiotami prawnymi. Chodzi o to, by nie zgubić pytania w przestrzeni między nimi.

Obok pierwszego rozróżnienia warto zachować jeszcze drugie. Klasyfikacja jako wysokiego ryzyka sama w sobie nie oznacza zgody, bezpieczeństwa, uczciwości ani zgodności z prawem. W swojej wspólnej opinii dotyczącej pierwotnego wniosku Komisji Europejska Rada Ochrony Danych i Europejski Inspektor Ochrony Danych podkreśliły, że zakwalifikowanie systemu jako wysokiego ryzyka nie oznaczało koniecznie, że był on zgodny z prawem jako taki ani że mógł być wdrożony przez jego użytkownika jako taki. Od czasu wydania tej opinii akt końcowy zmienił krajobraz prawny, ale leżące u jej podstaw ostrzeżenie pozostaje aktualne. Klasyfikacja jest warunkiem regulacyjnym. Nie jest pokwitowaniem, że instytucja może przestać myśleć.

To istotne, ponieważ etykieta wysokiego ryzyka może prowadzić do dwóch przeciwstawnych błędów. Jeden zespół może traktować ją jako trwałe piętno na modelu i uznać, że rozwiązaniem jest po prostu niepatrzenie dalej. Inny może traktować zakończony proces oceny zgodności jako przepustkę do dowolnego późniejszego kontekstu. Oba podejścia zastępują etykietą argument. Europa wybrała bardziej niewygodne podejście: zidentyfikuj system, jego cel i rolę, a następnie zbadaj istotne ryzyka i obowiązki w całym cyklu życia.

Zamierzone przeznaczenie jest punktem wyjścia analizy

Zamierzone przeznaczenie brzmi skromnie, niemal urzędniczo. Tak nie jest. Akt definiuje je jako zastosowanie, do którego system AI jest przeznaczony przez dostawcę, w tym szczególny kontekst i warunki użytkowania określone w informacjach dostarczonych przez dostawcę. Innymi słowy, przeznaczenie nie jest hasłem na stronie produktu. Obejmuje kontekst i warunki, w jakich dostawca wskazuje, że system ma być używany. Użyteczne sformułowanie przeznaczenia ma wyraźne granice. Mówi, co system robi, dla kogo, na podstawie jakich danych wejściowych, w ramach jakiego przepływu pracy i gdzie kończy się jego zakres uprawnień.

Porównaj dwa opisy. Pierwszy mówi, że system wykorzystuje AI, aby pomagać organizacjom w podejmowaniu lepszych decyzji. Jest na tyle ogólny, że zmieściłby się na tle konferencyjnym, i zbyt ogólny, by dało się według niego działać. Drugi mówi, że system przedstawia przeszkolonym recenzentom wstępne streszczenia istniejących akt sprawy z linkami do źródeł; nie może podejmować, przekazywać ani wdrażać decyzji; recenzent musi zweryfikować cytowane źródła przed skorzystaniem ze streszczenia; a funkcja jest niedostępna dla kategorii wymagających odrębnego postępowania ustawowego. Drugi opis jest mniej ekscytujący. Jest też czymś, z czym inżynier, kierownik ds. zakupów, współpracownik ds. zgodności i osoba, której sprawa dotyczy, mogą się konkretnie nie zgodzić.

Przeznaczenie nie musi być jednym zdaniem. W poważnym systemie jest to zwykle zwarty pakiet: zadanie, wynik, użytkownik, populacja, której dotyczy, środowisko, zakres uprawnień, wyłączenia, zależności i warunki. Wymogi aktu dotyczące dokumentacji technicznej pozostawiają miejsce właśnie na tego rodzaju opis. Załącznik IV wymaga ogólnego opisu systemu AI, w tym zamierzonego przeznaczenia, osób i grup, wobec których ma być stosowany, oraz konkretnych wersji lub form, w jakich jest wprowadzany na rynek. Wymaga również opisów architektury systemu, wymagań dotyczących danych, środków nadzoru ze strony człowieka, monitorowania cyklu życia i środków zarządzania ryzykiem. Dokumentacja ma taki zakres, ponieważ sama karta modelu nie może opisać wdrożenia.

Przeznaczenie to także moment, w którym zespół odkrywa, że opisywał ambicję, a nie działanie. Stwierdzenie, że będziemy wspierać pracowników socjalnych, może ukrywać kilkanaście różnych rozwiązań. Czy narzędzie przeszukuje dokumenty, porządkuje pracę, przygotowuje odpowiedź, rekomenduje kategorię, odrzuca wniosek, eskaluje alert, ustawia priorytet czy wywołuje inną usługę? Czy współpracownik korzysta z niego przed sformułowaniem niezależnej opinii, czy po? Czy wynik jest sugestią na bocznym panelu, czy polem, które należy wypełnić, zanim sprawa będzie mogła przejść dalej? Czy efekt jest natychmiastowy, opóźniony, odwracalny czy trudny do zauważenia? Odpowiedź zmienia system, nawet jeśli interfejs użytkownika wygląda znajomo.

Zamierzone przeznaczenie podane przez dostawcę nie sprawi, że rzeczywistość zniknie. Zespół nie może przyznać systemowi szerokiej praktycznej władzy, opisać go jako nieszkodliwego asystenta i oczekiwać, że ten opis załatwi sprawę. Jednak właściwie ograniczone przeznaczenie wciąż stanowi mechanizm kontroli. Mówi użytkownikom, jakie dowody wzięto pod uwagę, mówi integratorom, czego nie wolno im lekceważąco rozszerzać, i mówi recenzentom, jaka zmiana wymagałaby ponownej oceny. Niejasne przeznaczenie zamienia każde późniejsze pytanie w spór o to, co właściwie miano na myśli. Ograniczone przeznaczenie pozwala organizacji zapytać, czy wciąż robi to, co zatwierdziła.

Staje się to szczególnie istotne, gdy organizacja wprowadza istotną modyfikację. Akt zawiera przepisy dotyczące przypadków, w których dystrybutor, importer, podmiot wdrażający lub inna strona trzecia może stać się dostawcą, w tym gdy wprowadza system do obrotu pod własną nazwą, dokonuje istotnej modyfikacji lub zmienia zamierzone przeznaczenie w sposób powodujący, że system staje się systemem wysokiego ryzyka. Dokładne zastosowanie przepisów zależy od okoliczności faktycznych i należy je sprawdzić w danym kontekście. Wniosek operacyjny jest prostszy: zmiana integracji może być zdarzeniem o charakterze zarządczym. Przeniesienie wyniku modelu z okna roboczego do kolejki decyzyjnej może być jednocześnie zmianą produktu, zmianą przepływu pracy i zmianą odpowiedzialności.

Kontekst to nie dekoracja

Kontekst wdrożenia bywa traktowany jako element, który pojawia się po właściwej pracy: lista krajów, wybór hostingu, kilka person użytkowników, może diagram ze strzałkami prowadzącymi posłusznie od lewej do prawej. Ale to kontekst nadaje ryzyku kształt. Ten sam rodzaj wyniku może być uciążliwy w jednym otoczeniu i brzemienny w skutkach w innym. Błędne uzupełnienie w narzędziu do pisania można poprawić w następnym zdaniu. Błędny priorytet w przepływie pracy dotyczącym ograniczonych zasobów może zdecydować, który plik dana osoba zobaczy jako pierwszy. Wynik, który wydaje się jednym z wielu danych wejściowych, może stać się rozstrzygający, jeśli każde inne dane wejściowe są wolne, niejasne lub ukryte za innym zespołem.

Przyjęte w Akcie podejście do systemów wysokiego ryzyka to odzwierciedla. Artykuł 6 wiąże klasyfikację wysokiego ryzyka z systemami przeznaczonymi do stosowania jako elementy bezpieczeństwa niektórych produktów lub z systemami, o których mowa w załączniku III. Załącznik III wymienia obszary, w których systemy AI mogą być uznane za systemy wysokiego ryzyka, ponieważ są przeznaczone do określonych zastosowań, takich jak niektóre zastosowania biometryczne, infrastruktura krytyczna, edukacja i szkolenie zawodowe, zatrudnienie, dostęp do podstawowych usług prywatnych i publicznych oraz świadczeń, egzekwowanie prawa, migracja i zarządzanie granicami oraz wymiar sprawiedliwości i procesy demokratyczne. Szczegóły prawne mają znaczenie, ale znaczenie ma też gramatyka. Akt nie stwierdza, że artefakt techniczny jest wysokiego ryzyka w oderwaniu od kontekstu. Wielokrotnie mówi o przeznaczeniu do użycia.

Artykuł 6 zawiera również zastrzeżenie dotyczące niektórych systemów z załącznika III: nie są one uznawane za systemy wysokiego ryzyka, jeżeli nie stwarzają znaczącego ryzyka wyrządzenia szkody zdrowiu, bezpieczeństwu lub prawom podstawowym osób fizycznych, w tym poprzez brak istotnego wpływu na wynik podejmowania decyzji. Dostawcy muszą udokumentować tę ocenę przed wprowadzeniem systemu do obrotu lub oddaniem go do użytku. Nie jest to ogólna karta zwalniająca z obowiązków. To przypomnienie, że faktyczny wpływ systemu ma znaczenie. Przydatna analiza zawiera wystarczająco szczegółów, aby wyjaśnić, dlaczego system ma lub nie ma istotnego wpływu na wynik. Jeśli takiego wyjaśnienia nie da się napisać bez ogólników, zespół dowiedział się czegoś przed wydaniem.

Kontekst obejmuje czas. Rekomendacja na początku szeroko zakrojonego dochodzenia ma inny skutek niż rekomendacja w momencie, gdy dana osoba ma tylko jedną szansę na dostarczenie brakującego materiału. Obejmuje też wolumen. Indywidualny recenzent może zakwestionować wynik, gdy dziennie wpływa pięć spraw, a przyjmować go domyślnie, gdy przed południem wpływa ich pięćset. Obejmuje język. Recenzent, który może czytać dowody we własnym języku roboczym, może sprawować inny rodzaj nadzoru niż recenzent otrzymujący stanowcze streszczenie materiału, którego nie może samodzielnie zweryfikować. Obejmuje lokalną procedurę, prawa do odwołania, obsadę kadrową, dostęp do specjalisty, dostępność rozwiązania zastępczego oraz to, czy wynik trafia do osoby mającej wystarczające uprawnienia, by zrobić z nim coś pożytecznego.

Żadne z tych zagadnień nie wymaga, by wymyślona katastrofa była prawdziwa. To po prostu sposób, w jaki działają systemy. Formalna polityka może głosić, że człowiek jest w pętli, ale system może mimo to działać w praktyce automatycznie, jeśli dana osoba nie ma czasu, informacji, uprawnień ani praktycznej możliwości, by się sprzeciwić. Artykuł 14 ustawy mówi zatem o skutecznym nadzorze człowieka odpowiednim do ryzyka, poziomu autonomii i kontekstu użycia. Wymaga, aby systemy wysokiego ryzyka były projektowane i rozwijane tak, by ludzie mogli zrozumieć istotne możliwości i ograniczenia, pozostawać świadomi tendencji do automatycznego polegania na wynikach, poprawnie interpretować wyniki, zdecydować się ich nie używać, nadpisać je lub odwrócić oraz bezpiecznie zatrzymać system, gdy zachodzi taka potrzeba. To kwestie operacyjne. Nie można na nie odpowiedzieć wyłącznie na podstawie benchmarku modelu.

Wybierz postać wdrożenia. Model pozostaje na miejscu; granica systemu, uprawnienia i wymagane dowody już nie.

Użytkownicy są częścią powierzchni sterowania

Kuszone jest mówienie o użytkownikach tak, jakby znajdowali się poza systemem, trzymając klawiaturę i zapewniając ten ludzki element. Są częścią ustaleń operacyjnych. Ich wiedza, obciążenie pracą, uprawnienia, motywacje i drogi uzyskania pomocy decydują o tym, co robi wynik. System zaprojektowany dla specjalisty, który może przeglądać materiały źródłowe, nie jest automatycznie odpowiedni dla ogólnego pracownika, który ma pracować szybko. Narzędzie przydatne recenzentowi mogącemu odrzucić rekomendację nie jest automatycznie odpowiednie dla współpracownika, który może jedynie kliknąć „zatwierdź” albo czekać na kogoś innego.

Nie oznacza to, że użytkownik musi za każdym razem poddawać w wątpliwość każdy komponent. Byłaby to dziwna definicja użytecznej technologii. Oznacza to, że nadzór powinien być zaprojektowany jako realne zadanie. Osoba musi wiedzieć, kiedy system jest używany, jaka jest istotna ograniczenie, jakie dowody są dostępne, jaki rodzaj sprzeciwu może zgłosić i co się dzieje po jego zgłoszeniu. Potrzebuje uprawnień odpowiadających odpowiedzialności. Proszenie kogoś o nadzorowanie wyniku, którego nie może wstrzymać, poprawić ani skierować, to mniej nadzór człowieka, a bardziej dekoracja.

Rozporządzenie przyznaje tu rolę podmiotom wdrażającym. Artykuł 26 wymaga, aby podmioty wdrażające systemy wysokiego ryzyka podejmowały odpowiednie środki techniczne i organizacyjne w celu zapewnienia, że korzystają z systemów zgodnie z dołączonymi instrukcjami. Zobowiązuje je do powierzenia nadzoru człowieka osobom fizycznym posiadającym niezbędne kompetencje, szkolenie i uprawnienia oraz do monitorowania działania na podstawie instrukcji. W niektórych przypadkach wymaga również utrzymywania automatycznie generowanych dzienników pod ich kontrolą. Nie jest to prośba o trzymanie kompetentnej osoby w pobliżu na wypadek, gdyby interfejs się zdenerwował. To wymóg zorganizowania praktyki zawodowej.

Szkolenia często przedstawia się jako całe rozwiązanie. Tak nie jest. Szkolenie może pomóc osobie rozpoznać ograniczenie, ale nie stworzy źródła danych, które interfejs ukrywa. Nie stworzy czasu, który pochłania konstrukcja kolejki. Nie stworzy uprawnień, które umowa zastrzega gdzie indziej. Nie naprawi integracji, która zamienia ostrożne zalecenie w nieodwracalne działanie. Organizacja powinna oczywiście szkolić ludzi. Powinna również sprawić, aby zadanie, do którego ich szkoli, było możliwe do wykonania w systemie, który faktycznie otrzymują.

Istnieje użyteczny test: opisz działanie użytkownika bez użycia czasownika „przeglądać”. Co czytają? Jakie porównanie mogą przeprowadzić? Co mogą odrzucić? Gdzie trafia uzasadnienie? Kto je widzi? Co dzieje się z zaleceniem po odrzuceniu? Czy osoba, której dotyczy wynik, może zapytać, co się stało? Czy późniejszy współpracownik może odtworzyć istotny stan? Jeśli odpowiedzi pozostają ogólne, prawdopodobnie ogólny jest również projekt nadzoru.

Ten test wykracza poza systemy wysokiego ryzyka. Prawo ma określony zakres i daty; dobra ocena operacyjna nie czeka na etykietę kategorii, zanim zapyta, czy człowiek został umieszczony w roli performatywnej. Całkiem możliwe jest zbudowanie narzędzia o niskich konsekwencjach, które czyni ludzi mniej świadomymi własnej pracy, ponieważ wynik jest zbyt gładki, by go kwestionować. Możliwe jest również zbudowanie narzędzia z ograniczeniami, które zwiększa zdolność człowieka do zadawania dobrych pytań, ponieważ zachowuje dowody, ogranicza swoją władzę i czyni niepewność widoczną. Model może przyczynić się do obu wyników. To system decyduje, który wynik ma gdzie zaistnieć.

Osoby, których dotyczy system, siedzą poza konsolą

Wiele najważniejszych osób w systemie AI nigdy go nie dotyka. Mogą to być kandydat, uczeń, pracownik, pacjent, pasażer, mieszkaniec, klient, wnioskodawca, kredytobiorca, świadek lub członek społeczeństwa. Mogą nie wiedzieć, że w grę wchodził model. Mogą doświadczyć jedynie odpowiedzi, która przychodzi szybko, wniosku, który jest opóźniony, usługi, która staje się niedostępna, priorytetu, który się zmienia, lub decyzji, która wydaje się niemożliwa do zrozumienia. Ich nieobecność w interfejsie nie czyni ich nieobecnymi w systemie.

To jeden z powodów, dla których ramy ryzyka w rozporządzeniu odnoszą się do zdrowia, bezpieczeństwa i praw podstawowych. Kierują uwagę na konsekwencje, których nie można sprowadzić do tego, czy zalogowany współpracownik dobrze się bawił przy narzędziu. To także powód, dla którego deklaracja celu powinna wymieniać osoby i grupy, na których system ma być stosowany, zgodnie z wymogami załącznika IV. System zbudowany wokół kategorii zwanej „użytkownikiem” może po cichu ukryć różnicę między osobą obsługującą interfejs a osobą żyjącą z rezultatem.

Osoby dotknięte systemem zmieniają pytania, które zespół musi sobie zadać. Czy istnieje sposób, aby stwierdzić, że system odegrał znaczącą rolę? Czy decyzja opiera się na informacjach, które można skorygować? Czy język, niepełnosprawność, urządzenie, lokalizacja lub status administracyjny utrudniają udział? Czy zespół operacyjny otrzymuje sygnały od osób dotkniętych systemem, czy tylko z pulpitu nawigacyjnego? Czy korekta dociera do danych, rekomendacji, decyzji i wszelkich dalszych materiałów, które na nich polegały? Te pytania nie są prośbą o przekształcenie każdego systemu w konsultacje publiczne. Są prośbą o podążanie za konsekwencjami wystarczająco daleko, aby dostrzec osobę po drugiej stronie.

Prawo ochrony danych ma zastosowanie tam, gdzie przetwarzane są dane osobowe, obok ram prawnych aktu w sprawie sztucznej inteligencji. EDPB i EDPS jasno to podkreśliły w swojej wspólnej opinii z 2021 r. dotyczącej wniosku: istniejące unijne prawo ochrony danych stosuje się do przetwarzania danych osobowych w zakresie objętym wnioskiem. Dokładna analiza prawna będzie zależeć od przetwarzania i zaangażowanych podmiotów. Wniosek dla zarządzania jest prosty. Ćwiczenie klasyfikacyjne nie może pochłonąć wszystkich innych obowiązków. Prywatność, niedyskryminacja, obowiązki sektorowe, wymogi prawa administracyjnego, przepisy konsumenckie i zobowiązania umowne nie znikają, ponieważ zespół sporządził dobrze wyglądający rejestr ryzyka.

Istnieje również podstawowa kwestia czytelności. Osoba nie musi zostać specjalistą od uczenia maszynowego, aby zrozumieć, jak ubiegać się o korektę. System nie może jednak wykorzystywać złożoności technicznej jako powodu, aby uniemożliwić korektę. Dobra ścieżka rozróżnia, co system zarejestrował, co zdecydował człowiek, jakie dowody wzięto pod uwagę, co pozostaje niepewne i co można jeszcze zmienić. Nie rości sobie pretensji do precyzji, której rejestry nie mogą potwierdzić. W tej dziedzinie uczciwość to nie tylko ton głosu. To część usługi.

Integracja to moment, w którym odpowiedzialność przechodzi z rąk do rąk

Zespoły czasami przedstawiają architekturę sztucznej inteligencji jako uporządkowany łańcuch: model, prompt, odpowiedź, użytkownik. Rzeczywiste wdrożenia przypominają bardziej plan miasta po tym, jak ktoś przypomniał sobie o rurach serwisowych. Istnieją systemy tożsamości, magazyny wyszukiwania, uprawnienia narzędzi, kolejki, schematy, pamięci podręczne, platformy obserwowalności, rozszerzenia przeglądarki, zadania wsadowe, reguły zatwierdzania, ustawienia przechowywania, dostawcy i ludzie, którzy dziedziczą zadanie, ponieważ poprzednia osoba poszła na urlop. Model jest ważny. Rzadko jednak działa sam.

Każda integracja może zmienić możliwości systemu i sposób rozprzestrzeniania się błędu. Wyszukiwanie może sprawić, że wynik modelu będzie wyglądał na ugruntowany, podczas gdy źródło jest nieaktualne, niekompletne lub niewłaściwie zakresowane. Wywołanie narzędzia może przekształcić szkic w zmianę stanu. Kolejka może zmienić terminową rekomendację w spóźnioną. Warstwa orkiestracji może wybrać inny model lub wersję promptu. Interfejs użytkownika może ukrywać niepewność istniejącą w niższej warstwie. Integracja tożsamości może dać przydatnemu narzędziu dostęp do materiałów, których użytkownik w innym przypadku nie mógłby otworzyć. Żadna z tych obserwacji nie oskarża konkretnego produktu ani organizacji. Opisują one zwykłe właściwości systemów, co jest właśnie powodem, dla którego należy je udokumentować, zanim staną się zaskoczeniem.

Wytyczne Komisji dotyczące GPAI są tutaj przydatne, ponieważ umieszczają informacje w punkcie przekazania. Dokumentacja dla dostawców niższego szczebla ma pomóc im zrozumieć możliwości i ograniczenia modelu, jego przewidziane zadania, wymagania techniczne dotyczące integracji, specyfikacje wejścia i wyjścia oraz informacje o danych treningowych. Te informacje są niezbędne. Nie są jednak wystarczające. Zespoły niższego szczebla nadal muszą zdecydować, jak model jest promptowany, czy wynik jest wyświetlany z dowodami, jakie uprawnienia narzędzi są dozwolone, jak testowana jest zmiana, jakie logi są przechowywane oraz czy rekomendacja może wpływać na konkretny przepływ pracy.

Dlatego zakup usługi modelu nie jest zakupem kompletnego profilu ryzyka. Dokumentacja dostawcy może informować zespół, że model ma znane ograniczenie lub że został oceniony w określonych warunkach. Nie może jednak dowieść, że indeks wyszukiwania kupującego jest aktualny, że pracownicy kupującego mają wymagane uprawnienia ani że osoba, której sprawa dotyczy, ma dostęp do ścieżki odwoławczej. Z drugiej strony kupujący nie może wymagać, aby dostawca modelu znał każdą lokalną politykę czy proces na dalszym etapie. Odpowiedzialne podejście nie polega na udawaniu, że jedna strona może znać cały system. Polega na jednoznacznym wyznaczeniu granicy i utrzymywaniu przepływu dowodów przez tę granicę.

Artykuł 25 stanowi użyteczny prawny wyznacznik tej operacyjnej rzeczywistości. Określa okoliczności, w których podmiot inny niż pierwotny dostawca jest uznawany za dostawcę systemu AI wysokiego ryzyka. Należą do nich wprowadzenie systemu na rynek pod nazwą lub znakiem towarowym tego podmiotu, dokonanie istotnej modyfikacji lub zmiana przeznaczenia w sposób powodujący, że system staje się systemem wysokiego ryzyka. Przepis ten ma charakter techniczny i zależy od konkretnych okoliczności; nikt nie powinien samodzielnie dokonywać klasyfikacji na podstawie wpisu na blogu. Jednak jego kierunek jest jasny. Integracja i zmiana przeznaczenia mogą zmienić podmiot ponoszący obowiązki dostawcy. Uzgodnienie na dalszym etapie nie pozostaje na zawsze na dalszym etapie tylko dlatego, że pierwotny model pochodził skądinąd.

Istnieje instytucjonalny powód, aby traktować to poważnie. Gdy odpowiedzialność zmienia się po cichu, bezpieczeństwo i dochodzenie roszczeń stają się grą w organizacyjny ping-pong. Dostawca modelu wskazuje na wdrożenie. Wdrażający wskazuje na model. Integrator wskazuje na usługę w chmurze. Właściciel usługi wskazuje na konfigurację, która już nie istnieje. Osoby, których sprawa dotyczy, otrzymują dopracowane wyjaśnienie, jak wszystko jest skomplikowane. Może to być zgodne z prawdą, ale nie jest odpowiedzią. System potrzebuje rejestru tego, która organizacja odpowiada na pytanie na każdej granicy, oraz ścieżki, którą pytanie może podążać, gdy odpowiedź znajduje się gdzie indziej.

Dokumentacja powinna opisywać system, który wciąż może się zmieniać

Dokumentacja techniczna ma reputację powstającej na końcu projektu z lekkim zapachem paniki. Rozporządzenie opisuje inną rolę. W przypadku systemów wysokiego ryzyka dokumentacja techniczna musi zostać sporządzona przed wprowadzeniem systemu na rynek lub oddaniem go do użytku i musi być na bieżąco aktualizowana. Lista w załączniku IV wykracza poza zachowanie modelu i obejmuje przeznaczenie, wersje, architekturę systemu, rozwój, wymagania dotyczące danych, walidację i testowanie, nadzór człowieka, dokładność i środki cyberbezpieczeństwa, zarządzanie ryzykiem, zmiany oraz monitorowanie po wprowadzeniu na rynek. To nie jest ozdobny aneks. To próba zachowania wystarczającej pamięci, aby ktoś mógł sprawdzić system, gdy spotkanie po wdrożeniu stanie się już tylko wspomnieniem.

Dokumentacja działa tylko wtedy, gdy potrafi pokazywać zależności. Wersja modelu musi być powiązana z wersją systemu, która jej używała. Test musi być powiązany z warunkami wejściowymi i celem. Polityka musi być powiązana z punktem egzekwowania. Rola użytkownika musi być powiązana z uprawnieniami, jakie ma w interfejsie. Polityka logowania musi być powiązana ze zdarzeniem, które może odtworzyć. Zmiana musi być powiązana z oceną, którą wywołała. W przeciwnym razie zespół ma bibliotekę dobrych dokumentów, ale nie ma sposobu, aby odpowiedzieć na konkretne pytanie.

Logi to podobny przypadek. Artykuł 12 wymaga, aby systemy AI wysokiego ryzyka miały możliwości techniczne automatycznego rejestrowania zdarzeń przez cały okres użytkowania systemu, proporcjonalnie do zamierzonego celu. Logi mogą wspierać identyfikowalność, monitorowanie po wprowadzeniu do obrotu oraz monitorowanie operacyjne. Nie wyjaśniają jednak decyzji w magiczny sposób. Log może późniejszemu śledczemu powiedzieć, że narzędzie zostało wywołane, że działała określona wersja lub że recenzent kliknął daną kontrolkę. Sam w sobie nie może ustalić, czy recenzent zrozumiał dowody, czy źródło danych było wiarygodne ani czy proces był sprawiedliwy. Rejestry są cenne, ponieważ dają dochodzeniu uczciwy punkt wyjścia, a nie dlatego, że eliminują potrzebę osądu.

Monitorowanie po wprowadzeniu do obrotu uzupełnia cały obraz. Artykuł 72 wymaga, aby dostawcy systemów wysokiego ryzyka ustanowili i udokumentowali system monitorowania po wprowadzeniu do obrotu w sposób proporcjonalny do charakteru technologii i ryzyka związanego z systemem AI wysokiego ryzyka. Ma to prostą implikację dla zespołów wdrożeniowych: wydanie nie jest momentem, w którym system staje się w pełni poznany. Organizacja potrzebuje sposobu na otrzymywanie istotnych informacji, odróżnianie sygnału od wniosku, ocenę, czy granica zamierzonego celu nadal obowiązuje, oraz na wprowadzenie zmiany lub zaprzestanie użytkowania, gdy wymagają tego dowody.

Ta praca nie jest efektowna. Wygląda jak identyfikatory wersji, jasne kryteria wydania, rejestr zależności, test ścieżki wycofania, wyznaczony właściciel ograniczenia oraz decyzja, która pozostaje widoczna po tym, jak osoba ją podejmująca zmieni stanowisko. Wygląda jak pytanie o to, czy integracja się zmieniła, zanim zapytamy, czy zmienił się model. Wygląda jak zachowanie wystarczającej ilości dowodów, aby naprawić konsekwencję, a nie tylko wyjaśnić ją po fakcie. Nuda nie jest tutaj przeciwieństwem ambicji. Jest tym, co pozwala ambicji zmieścić się w instytucji.

Jak myśleć o całym systemie bez udawania pewności

Pełna analiza nie jest poszukiwaniem uniwersalnego wyniku ryzyka. To ciąg pytań, które stają się coraz bardziej precyzyjne wraz z precyzją projektu. Pierwsze pytanie dotyczy celu: co ten system ma robić, a czego konkretnie nie ma robić? Drugie dotyczy konsekwencji: kto może zostać dotknięty, w jaki sposób i za pośrednictwem której decyzji lub usługi? Trzecie dotyczy uprawnień: które dane wyjściowe mogą zmienić stan, wpłynąć na decyzję, ustalić priorytet lub zmienić to, co otrzymuje dana osoba? Czwarte dotyczy dowodów: co potwierdza użycie systemu w tym kontekście i jakie warunki sprawiają, że te dowody są wiarygodne?

Potem pojawiają się niewygodne pytania. Co się dzieje, gdy model jest niepewny, błędny, niedostępny lub używany poza zadeklarowanym zakresem? Co się zmienia, gdy źródło jest nieaktualne lub narzędzie jest zablokowane? Co, jeśli użytkownik jest w pośpiechu, nowy na stanowisku lub nie może sprawdzić materiałów źródłowych? Co, jeśli osoba, której dotyczy decyzja, poprosi o korektę? Co, jeśli aktualizacja zmieni prompt, korpus wyszukiwania, domyślny interfejs, wersję modelu lub uprawnienia roli? Odpowiedzią jest czasem kontrola techniczna, czasem procedura, czasem węższe zastosowanie, czasem inny właściciel, a czasem decyzja o niewdrażaniu. Zarządzanie, które nigdy nie dopuszcza tej ostatniej odpowiedzi, jest jedynie akceptacją w ładniejszym opakowaniu.

Pomocne jest rozdzielenie kilku stwierdzeń. Potwierdzony fakt mówi, co dostawca modelu udokumentował lub co organizacja zaobserwowała w zdefiniowanym teście. Wnioskowanie mówi, dlaczego ten fakt może mieć znaczenie w konkretnym przepływie pracy. Proponowana kontrola mówi, co zespół zamierza wdrożyć. Ryzyko rezydualne mówi, co pozostaje po wdrożeniu kontroli. Wniosek prawny mówi, co wynika z prawa. Te kategorie nie są wymienne. Dobry dokument je etykietuje, ponieważ czytelnik może potrzebować zakwestionować jedno stwierdzenie bez odrzucania pozostałych.

Na przykład można powiedzieć: dokumentacja dostawcy stwierdza, że model ma określone ograniczenie; zespół wdrożeniowy wnioskuje, że ograniczenie to może wpłynąć na wskazane zastosowanie; zespół proponuje bramkę weryfikacji źródła; bramka nie została jeszcze przetestowana w docelowym obciążeniu; a dział prawny musi ocenić wynikające z tego zastosowanie w świetle obowiązującego prawa. Takie zdanie jest mniej satysfakcjonujące niż zielony znacznik. Jest bardziej użyteczne niż zielony znacznik, ponieważ nie pozostawia wątpliwości co do tego, co zostało ustalone, a co nie.

Zespoły powinny szczególnie uważać na słowo człowiek. Rola człowieka może być kontrolą, ale tylko wtedy, gdy ma określone zadanie, odpowiednie informacje, czas, szkolenie, uprawnienia i możliwość działania. Rola człowieka może też stać się sposobem na przeniesienie winy na osobę siedzącą najbliżej ekranu. To rozróżnienie nie ma charakteru filozoficznego. Jest widoczne w przepływie pracy. Jeśli recenzent może tylko zatwierdzić, jeśli sprzeciw znika w niemonitorowanym polu komentarzy lub jeśli nikt nie może skorygować późniejszych konsekwencji, system nie zyskał znaczącego nadzoru tylko dlatego, że ktoś coś kliknął.

Ta sama ostrożność dotyczy przejrzystości. Długi dokument może sprawić, że system będzie opisywalny, ale niekoniecznie podważalny. Pulpit nawigacyjny może uczynić system widocznym, ale niekoniecznie zrozumiałym. Informacja może powiedzieć użytkownikowi, że w grę wchodzi AI, ale nie powiedzieć mu, co można zrobić z błędem. Użyteczne pytanie ma charakter praktyczny: czy właściwa osoba może znaleźć granicę, dowody, odpowiedzialną rolę i ścieżkę korekty w miejscu, w którym te rzeczy mają znaczenie? Jeśli nie, informacja znajduje się w niewłaściwym miejscu, aby nadzór mógł zaistnieć.

Krótka uwaga od nas

W Dweve nasze publiczne Centrum Zaufania traktuje kartę modelu i integrację downstream jako powiązane, ale odrębne karty. Strona downstream mówi, że zespoły integrujące lub wdrażające Loom potrzebują aktualnych możliwości, ograniczeń, interfejsów, kontekstu oceny i zmian, podczas gdy karta publiczna stwierdza, że model jest jednym wątkiem w szerszej tkaninie komponentów i granic operacyjnych. Jest to postawa dokumentacyjna, a nie twierdzenie, że publiczna strona klasyfikuje każde możliwe wdrożenie lub potwierdza zgodność dla integratora. Cel tego rozdzielenia jest skromniejszy: karta modelu powinna podróżować z integracją, nie udając, że zastępuje analizę systemu przeprowadzaną przez integratora.

To jest standard, którego warto się trzymać. Dostawca modelu powinien udostępniać użyteczne informacje. Organizacja, która wdraża lub integruje model, powinna opisać faktyczny system, który stworzyła: cel, ludzi, dane, interfejsy, uprawnienia, monitorowanie i korektę. Żadna ze stron nie powinna traktować dokumentacji jako ceremonialnej wymiany, w której jedna strona otrzymuje plik PDF, a druga rozgrzeszenie.

Trudniejsze pytanie jest zwykle lepsze

Gdy zespół pyta, czy model jest wysokiego ryzyka, może szukać szybkiej odpowiedzi na słuszną obawę. Ale bardziej użyteczne pytanie jest zwykle dłuższe: jaki system tworzymy z tego modelu, w jakim celu, w jakim kontekście, z jakimi ludźmi i co się stanie, gdy system się myli? Na to pytanie nie zawsze można odpowiedzieć na jednym spotkaniu. Może się okazać, że proponowane zastosowanie jest węższe, niż oczekiwano, że dowody są niekompletne, że rola użytkownika nie ma uprawnień, że umowa pozostawia ważną granicę bez właściciela lub że integracja downstream po cichu stała się centrum systemu.

Żadne z tych ustaleń nie jest porażką innowacji. To rzeczy, których instytucja uczy się, zanim przyzna systemowi władzę kształtowania czyichś możliwości. Podejście europejskie często opisuje się jako zbiór obowiązków. Jest to także dyscyplina nazywania: nazwij cel, podmiot, kontekst, wersję, osobę, której sprawa dotyczy, ograniczenie, dowody i drogę do interwencji. Gdy te rzeczy zostaną nazwane, można je testować, zmieniać i kwestionować. Zanim zostaną nazwane, zwykle pojawiają się później jako zaskoczenie.

Model może być wydajny, starannie udokumentowany i wartościowy. Może też zostać umieszczony w systemie, który wymaga od niego zbyt wiele, ukrywa zbyt wiele przed użytkownikami lub pozostawia zbyt mało miejsca osobie, której dotyczy wynik. Różnica powstaje poza wagami. To tam znajduje się trudna praca, a także poważna szansa: buduj systemy, których autorytet odpowiada ich dowodom, których granice przetrwają integrację i których operatorzy wciąż mogą powiedzieć nie.

Źródła