Mały model może nieść wielką odpowiedzialność

Rozmiar modelu to właściwość inżynieryjna. Obowiązek wynika z celu, kontekstu, danych, uprawnień i ludzi wokół systemu.

Mały model może nieść wielką odpowiedzialność

Prawo nie pyta, jak duży jest model

Otwórz unijny akt o sztucznej inteligencji, a nie spotkasz licznika modeli. Nie ma pierwszej strony, na której maszyna jest ważona, mierzona i umieszczana w schludnej prawniczej szufladzie. Akt zaczyna się od systemu: systemu opartego na maszynie, który działa z różnym poziomem autonomii, może dostosowywać się po wdrożeniu i na podstawie danych wejściowych wnioskuje, jak generować przewidywania, treści, rekomendacje lub decyzje, które mogą wpływać na środowisko fizyczne lub wirtualne. Jego definicja dotyczy tego, co system robi i co mogą zmienić jego wyniki.

To dobre miejsce na początek, bo rozmowa o technologii wciąż próbuje sprawić, by rozmiar zastąpił kontekst. Mniejszy model brzmi skromnie. Może zmieścić się na zwykłym sprzęcie, odpowiadać na jedno wąskie pytanie albo zwracać etykietę zamiast akapitu. To mogą być cenne właściwości inżynieryjne. Mogą zmniejszyć powierzchnię, którą trzeba przetestować, obniżyć zapotrzebowanie wdrożenia na zasoby albo ułatwić wymianę komponentu. Żadna z nich nie mówi nam, czy człowiek może stracić prawo, usługę, pracę lub bezpieczną trasę z powodu tej etykiety.

Obowiązek pojawia się w relacji między systemem a otaczającym go światem. Kto korzysta z wyniku. Jaka decyzja po nim następuje. Jakie dane trafiają na ścieżkę. Jak dużą władzę ma system. Czy człowiek może zakwestionować wynik. Czy ktoś może go cofnąć, zanim szkoda stanie się trwała. Czy osoba, której dotyczy wynik, jest od niego zależna, być może dlatego, że nie ma praktycznej alternatywy. Model może być technicznie mały, a instytucjonalnie duży. To jest teza tego artykułu, a słowo instytucjonalnie robi tu najcięższą pracę.

To nie jest argument za traktowaniem każdego klasyfikatora jak publicznego zagrożenia. To argument za proporcjonalnością. Proporcjonalność nie oznacza, że małe systemy dostają ceremonialny uśmiech i żadnych pytań. Oznacza, że pytania podążają za rzeczywistą konsekwencją. Model używany do porządkowania prywatnej kolekcji notatek i model używany do decydowania, kto zostanie poddany kontroli, mogą wyglądać podobnie w repozytorium. Nie są podobne w świecie.

Rozmiar modelu opisuje komponent. Cel, osoby, których dotyczy, i kontrola decydują o obowiązku, jaki niesie ten komponent.

Mały to pomiar, nie kontekst

Mały może oznaczać kilka różnych rzeczy, a znaczenia te bywają po cichu zamieniane. Może oznaczać mniejszą liczbę parametrów, mniejszy ślad pamięciowy, mniejsze zużycie mocy obliczeniowej do trenowania, ograniczone słownictwo, wąski schemat wyjściowy lub krótkie okno wejściowe. Może oznaczać, że model działa na urządzeniu, a nie za pośrednictwem zdalnej usługi. Może też oznaczać, że zespół powierzył modelowi wąskie zadanie. To nie są te same twierdzenia. Niewielka liczba parametrów nie oznacza niewielkiej roli społecznej, tak jak duża liczba parametrów nie mówi, gdzie systemowi wolno działać.

Istnieje też drugie nieporozumienie. Ludzie używają słowa mały w znaczeniu lokalny, a lokalny w znaczeniu nieszkodliwy. Lokalne wdrożenie może poprawić kontrolę nad przepływem danych, dostępnością lub własnością operacyjną. Może też umieścić decyzję bezpośrednio w miejscu pracy, przy publicznym okienku, w procesie medycznym lub w urządzeniu, którego człowiek nie może łatwo opuścić. Fizyczna bliskość może zmniejszyć jeden rodzaj zależności, jednocześnie zwiększając znaczenie osób obsługujących system. Serwer w tym samym budynku nie jest kategorią moralną.

Jest jeszcze mały jako obietnica dotycząca możliwości. Komponent może być trenowany do jednego zadania, a mimo to wpływać na większy proces. Może zwracać tylko zatwierdź, przejrzyj lub odmów. Dalszy przepływ pracy może traktować te trzy słowa jako bramkę. Komponent nie musi pisać wypracowania, aby podjąć znaczącą decyzję. Wystarczy, że zostanie umieszczony w miejscu, w którym kolejny system lub kolejna osoba nie może go łatwo zakwestionować.

Dla zarządzania użyteczną jednostką nie jest zatem sam model. Jest to model wdrożony, z celem, operatorem, granicą wejściową, kontraktem wyjściowym, działaniem w dalszym procesie i ścieżką korekty. To mniej uporządkowane niż ranking. Jest też bliższe rzeczywistości. Ranking może powiedzieć, jak model poradził sobie z zadaniem. Nie może powiedzieć, czy to zadanie było dozwolone, czy osoby, których dotyczyło, mogły się sprzeciwić, ani czy organizacja miała uprawnienia do wykorzystania wyniku.

Język Komisji Europejskiej dotyczący sztucznej inteligencji ogólnego przeznaczenia po cichu ilustruje to rozróżnienie. Komisja podaje kryteria techniczne, które mają pomóc ustalić, kiedy model może podlegać obowiązkom GPAI, ale jednocześnie stwierdza, że kryteria te mają charakter orientacyjny i konieczna pozostaje ocena indywidualna. Wytyczne nie udają, że jedna liczba może opisać każdą rolę, jaką model może pełnić. Próbują uczynić jedno pytanie klasyfikacyjne wykonalnym, nie zamieniając go w uniwersalną teorię szkody.

Próg nie jest wyrokiem

W akcie o sztucznej inteligencji są liczby, co jest jednym z powodów, dla których ludzie sięgają po liczby, gdy chcą pewności. Artykuł 51 tworzy domniemanie możliwości o wysokim wpływie dla modelu sztucznej inteligencji ogólnego przeznaczenia trenowanego przy skumulowanej ilości obliczeń większej niż 1025 operacji zmiennoprzecinkowych. To domniemanie należy do klasyfikacji modeli GPAI z ryzykiem systemowym. Nie jest to zasada, że model poniżej progu jest bezpieczny, ani zasada, że każdy model powyżej progu powoduje taką samą szkodę.

Wytyczne Komisji dotyczące GPAI stosują inny orientacyjny próg, powyżej 1023 operacji zmiennoprzecinkowych wraz z szerokimi możliwościami generatywnymi, aby pomóc zidentyfikować modele, które mogą być ogólnego przeznaczenia. Strona wyraźnie wskazuje ograniczenia. Model poniżej wskaźnika może nadal kwalifikować się, jeśli wykazuje znaczną ogólność. Model, który go spełnia, może wyjątkowo nie kwalifikować się, jeśli brakuje mu odpowiedniej ogólności. Wytyczne są interpretacją dla konkretnego pytania prawnego, a nie przepustką do każdego zastosowania w dalszym procesie.

Te dwa progi są użyteczne właśnie dlatego, że są wąskie. Pomagają organom i dostawcom uporządkować konkretną klasę obowiązków dotyczących modeli. Nie rozstrzygają, czy mały model osadzony w systemie wysokiego ryzyka wymaga szczególnej staranności. Nie rozstrzygają, czy przetwarzanie danych jest zgodne z prawem. Nie rozstrzygają, czy osoba może zakwestionować decyzję. Próg może ustalić, że należy zadać pytanie. Nie może odpowiedzieć na pytanie, które należy do innej warstwy.

Progi techniczne również się starzeją. Rozporządzenie stanowi, że Komisja może dostosować próg ryzyka systemowego w świetle rozwoju technologicznego, w tym ulepszeń algorytmicznych i wydajności sprzętu. Wytyczne Komisji wskazują, że jej własne kryterium nie jest bezwzględne. To rozsądne przyznanie. Liczba, która wygląda na stabilną w arkuszu przetargowym, może się zmienić, gdy zmieni się otaczająca ją technologia. Właściwa reakcja nie polega na nieufności wobec każdej liczby. Polega na utrzymaniu liczby w powiązaniu z pytaniem, na które miała odpowiadać.

Jest praktyczna lekcja dla zespołów publikujących karty modeli lub wewnętrzne notatki architektoniczne. Należy podać próg, jednostkę, przepis prawny i granicę. Należy wskazać, czy liczba jest domniemaniem prawnym, wskaźnikiem Komisji, warunkiem odniesienia czy wewnętrznym celem projektowym. Nie należy pozwalać, aby jedna metryka zyskała szersze znaczenie tylko dlatego, że jest wygodna na slajdach. Mała metryka może też nieść duży obowiązek. Liczba potrzebuje własnego pochodzenia.

System to więcej niż model w środku

Rozporządzenie o sztucznej inteligencji czyni granicę systemu widoczną. Definiuje dostawców i podmioty wdrażające, oddziela modele od systemów i przypisuje obowiązki wzdłuż łańcucha wartości. Dostawcą może być osoba lub organizacja, która opracowuje system lub zleca jego opracowanie i wprowadza go na rynek lub oddaje do użytku pod własną nazwą. Podmiotem wdrażającym jest osoba lub organizacja korzystająca z systemu w ramach swojej władzy. Te role mają znaczenie, ponieważ ten sam komponent bazowy może znajdować się w różnych układach z różnymi obowiązkami.

Wyobraźmy sobie kompaktowy klasyfikator tekstu, który zwraca jedną z czterech kategorii. Model nie ma interfejsu użytkownika, pamięci ani możliwości wywoływania narzędzia. W jednym ustawieniu sortuje dokumenty zespołu do folderów. W innym oznacza wnioski dla usługi publicznej, tak że niektóre osoby kierowane są do dodatkowej weryfikacji. Komponent może być technicznie identyczny. Drugi system ma inny cel, innych ludzi, których dotyczy, inną relację władzy oraz inną potrzebę wyjaśnień i środków zaradczych.

Zasady klasyfikacji wysokiego ryzyka w rozporządzeniu podążają za tego rodzaju różnicą. Sprawdzają, czy system jest komponentem bezpieczeństwa, czy jest używany w obszarze wymienionym w załączniku III oraz czy stwarza istotne ryzyko dla zdrowia, bezpieczeństwa lub praw podstawowych. Ścieżka wymienionego zastosowania nie jest oceną elegancji modelu. Jest oceną tego, co system robi w środowisku, w którym błędny wynik może mieć znaczenie. Wąskie zadanie proceduralne może mieścić się w starannie sformułowanym wyjątku, jeśli nie wpływa w istotny sposób na decyzję, ale dostawca musi udokumentować tę ocenę.

Tego wymogu dokumentacyjnego łatwo nie docenić. Zespół, który twierdzi, że system ma charakter wyłącznie przygotowawczy, składa twierdzenie o przyczynowości. Mówi, że wynik nie wpływa w istotny sposób na decyzję, która następuje później. Jeśli recenzent traktuje etykietę jako powód do otwarcia sprawy, jeśli personel ulega rankingowi lub jeśli wnioskodawca nie ma znaczącej możliwości skorygowania danych stojących za oznaczeniem, praktyczny wpływ może być większy, niż sugeruje interfejs. Słowo przygotowawczy nie może oznaczać niewidzialny.

Granice systemu obejmują również niepozorne elementy otaczające model: źródło danych, próg, kolejkę, osobę otrzymującą wynik, zapis, który pozostaje, umowę z dostawcą, proces aktualizacji oraz ścieżkę zatrzymania przepływu pracy. Mały model może być widocznym obiektem, podczas gdy prawdziwe ryzyko tkwi w przekazaniu. Dlatego przegląd ryzyka, który pyta tylko o to, co przewiduje model, jest niekompletny. Trudniejsze pytanie brzmi: co organizacja robi, ponieważ model to przewidział.

Cel zmienia znaczenie tego samego wyniku

Wynik nie ma żadnego zobowiązania w próżni. To samo prawdopodobieństwo, kategoria lub rekomendacja mogą być nieszkodliwe w jednym zadaniu, a brzemienne w skutkach w innym. Nie dzieje się tak dlatego, że słowa zmieniają swoje słownikowe znaczenie. Dzieje się tak, ponieważ wynik wchodzi w strukturę decyzyjną. Ranking używany do wyboru, które notatki badawcze przeczytać najpierw, to nie to samo co ranking decydujący o tym, które gospodarstwo domowe zostanie objęte dochodzeniem w sprawie oszustwa. Maszyna może używać tej samej matematyki. Instytucja nie ma jednak takiej samej relacji z ludźmi po drugiej stronie.

Artykuł 7 aktu o sztucznej inteligencji wymienia kryteria, które Komisja musi wziąć pod uwagę przy dodawaniu lub modyfikowaniu przypadków użycia wysokiego ryzyka. Należą do nich zamierzony cel, zakres faktycznego lub prawdopodobnego wykorzystania systemu, charakter i ilość danych, autonomia i możliwość interwencji człowieka, zakres i intensywność możliwych szkód, zależność od wyniku, nierównowaga sił, podatność na zagrożenia, odwracalność, korzyści oraz dostępność środków odwoławczych. Czytane łącznie kryteria te stanowią użyteczną odpowiedź na myślenie w kategoriach rozmiaru modelu. Opisują relację, a nie plik wag.

Komponent pozostaje mały, podczas gdy otaczający cel, władza, zależność i odwracalność zmieniają pytanie o kontrolę.

Zależność jest szczególnie istotna. Osoba może czasem zignorować rekomendację, skorzystać z innej usługi lub poprosić kolegę o sprawdzenie odpowiedzi. Może też nie mieć praktycznej alternatywy. Jeśli zautomatyzowany etap przesiewowy decyduje o tym, czy usługa zostanie opóźniona, czy wniosek otrzyma uwagę, czy pracownik zostanie wezwany na spotkanie, osoba, której to dotyczy, może być zmuszona żyć z pierwszą interpretacją systemu, podczas gdy organizacja decyduje, czy spojrzeć na sprawę ponownie. Im mniejsza widoczna decyzja, tym łatwiej przeoczyć zależność pod spodem.

Odwracalność ma znaczenie z tego samego powodu. Literówka w wewnętrznym tagu może zostać naprawiona, zanim ktokolwiek na niej polega. Flaga ryzyka może zmienić kolejność rozpatrywania sprawy, a samo opóźnienie może mieć konsekwencje. Odmowa może prowadzić do niedotrzymania terminu. Ranking może stać się jedynym rankingiem, jaki widzi zapracowany zespół. Fakt, że administrator technicznie może edytować bazę danych, nie dowodzi, że skutek społeczny jest łatwy do odwrócenia. Odwracalność techniczna i odwracalność odczuwalna są ze sobą powiązane, ale nie są tożsame.

W tym miejscu proporcjonalność nabiera treści. Wewnętrzna sugestia o niewielkim wpływie może wymagać lekkiego zapisu i jasno wskazanego właściciela. System, który wpływa na dostęp do usługi publicznej, potrzebuje mocniejszej ścieżki dowodowej, poinformowanej ścieżki ludzkiej oraz sposobu na zakwestionowanie danych wejściowych i wyniku. Proporcjonalne kontrole to nie brak kontroli. To kontrole wybrane, ponieważ relacja na nie zasługuje.

Dane zachowują swoje obowiązki

Rozmiar modelu nie czyni danych anonimowymi przez samą atmosferę. Opinia 28/2024 Europejskiej Rady Ochrony Danych mówi, że to, czy model AI można uznać za anonimowy, należy oceniać indywidualnie dla każdego przypadku. Test w publicznym streszczeniu EROD pyta, czy jest bardzo mało prawdopodobne, że model może bezpośrednio lub pośrednio zidentyfikować osoby, których dane wykorzystano do jego stworzenia, oraz czy jest bardzo mało prawdopodobne, że ich dane osobowe można wyodrębnić za pomocą zapytań. Mniejszy model może zawierać mniej informacji, ale mniej to nie wniosek prawny.

EROD uwzględnia również kontekst uzasadnionego interesu. Jej analiza wskazuje na konieczność i wyważenie oraz wymienia relację między osobami a administratorem, charakter usługi, kontekst, w którym dane zostały zebrane, źródło, możliwe dalsze wykorzystania oraz to, czego osoby mogły racjonalnie oczekiwać. Te czynniki nie znikają, gdy model jest kompresowany, destylowany, kwantyzowany lub umieszczany za zgrabnym API. Kompresja zmienia obiekt techniczny. Nie przepisuje historii tego, dlaczego dane zostały zebrane ani co powiedziano osobom.

Czytanie tej opinii w zestawieniu z inżynierią modeli to pożyteczna dyscyplina. Zapytaj, do czego model był trenowany lub adaptowany, jakie dane otrzymuje w czasie działania, które rekordy są przechowywane i kto może go zapytać. Następnie zapytaj, co dzieje się dalej. Czy wynik jest kopiowany do akt sprawy. Czy ranking staje się instrukcją. Czy recenzent-człowiek widzi materiał źródłowy, czy tylko etykietę modelu. Czy osoba, której sprawa dotyczy, ma możliwość poprawienia błędu faktycznego. To pytania o dane i zarządzanie, a nie tylko o dokładność.

Publiczne streszczenie EROD zauważa również, że wykorzystanie bezprawnie przetwarzanych danych osobowych w rozwijaniu modelu może wpłynąć na zgodność z prawem wdrożenia, chyba że model został należycie zanonimizowany. To zdanie opiera się znanej drodze ucieczki. Zespół nie może sprawić, że problem zniknie, mówiąc, że końcowy model jest mały, dane nie są już widoczne lub że model jest tylko jednym z elementów. Historia prawna i etyczna danych pozostaje częścią historii systemu.

Dla inżynierów oznacza to, że rejestr treningowy i rejestr wdrożeniowy nie powinny być traktowane jako odrębne światy. Dla zamówień publicznych oznacza to, że oświadczenie dostawcy o rozmiarze modelu nie zastępuje pochodzenia danych, celu, retencji, obsługi praw ani dokumentacji dalszych kroków. Dla osoby, której sprawa dotyczy, oznacza to, że użyteczne pytanie nie brzmi, ile parametrów było zaangażowanych. Chodzi o to, co stało się z jej informacjami i co organizacja może zrobić, gdy wynik jest błędny.

Mały sygnał może przesunąć dużą kolejkę

Rozważmy hipotetyczne biuro obsługi, które przyjmuje zgłoszenia od mieszkańców. Kompaktowy klasyfikator czyta pierwszą wiadomość i przypisuje trasę: informacja, praca rutynowa, pilny przegląd lub obsługa specjalistyczna. Przykład jest celowo zwyczajny i w całości poglądowy. Nie ma tu żadnej nazwanej rady, żadnego rzeczywistego wdrożenia, żadnej daty ani twierdzenia, że coś takiego miało miejsce. Chodzi o to, aby uwidocznić granicę.

Jeśli kategorie służą jedynie temu, by pracownik uporządkował prywatny zestaw notatek, ryzyko może być niewielkie. Jeśli pilna trasa decyduje o tym, kto otrzyma kontrolę bezpieczeństwa, wynik znajduje się już bliżej decyzji publicznej. Jeśli brakujące słowo kluczowe skieruje czyjeś zgłoszenie do pracy rutynowej, opóźnienie może mieć znaczenie, nawet jeśli model nigdy nie rozmawia z mieszkańcem. Jeśli pracownik może zobaczyć oryginalną wiadomość, zmienić trasę, zapisać powód i szybko odpowiedzieć na zakwestionowanie, system ma inną pozycję kontrolną niż taki, w którym etykieta staje się ukrytą bramką.

Model nie stał się większy. Obowiązek stał się wyraźniejszy. Prowadzi on od danych wejściowych do konsekwencji. Organizacja musi wiedzieć, co oznaczają kategorie, jakich dowodów model może użyć, które przypadki wymagają odmowy lub eskalacji, kto może zmienić trasę oraz jaki zapis pozwoli późniejszemu recenzentowi zrozumieć decyzję. Skromność modelu nie jest powodem, by pomijać te pytania. Może być powodem, by odpowiedzieć na nie precyzyjniej, ponieważ kontrakt tego komponentu można zawęzić.

Podobny hipotetyczny przykład pojawia się w zatrudnieniu. Niewielki model mógłby wyciągać umiejętności z CV, klasyfikować stanowisko lub oznaczać brakujący certyfikat. Ekstrakcja brzmi mniej doniośle niż selekcja, ale to ekstrakcja może kształtować późniejsze rankingowanie. Jeśli wynik nigdy nie służy do decydowania o tym, kto przechodzi dalej, system może pozostać po przygotowawczej stronie granicy. Jeśli ludzie traktują wyodrębnioną etykietę jako obiektywne podsumowanie i przestają zaglądać do dokumentu, granica się przesuwa. Obowiązek tkwi w użyciu, a nie w czasowniku wybranym do opisu zadania modelu.

W obu ilustracjach właściwą reakcją nie jest panika z powodu małego modelu. Chodzi o to, by przekazanie było jawne. Nazwij zamierzony cel. Określ, co wynik może, a czego nie może zmienić. Zachowaj źródło i wersję modelu tam, gdzie decyzja od nich zależy. Daj człowiekowi wystarczająco dużo informacji i uprawnień, by mógł się nie zgodzić. Przetestuj wycinki, w których system ma być niepewny. Przejrzyj przepływ pracy, gdy organizacja zmienia dane, próg, odbiorców lub działanie następcze.

Czego naprawdę uczy holenderski wyrok w sprawie SyRI

Europa ma już udokumentowany przykład kompaktowo wyglądającego systemu ryzyka niosącego obowiązek o ciężarze porównywalnym z prawami jednostki. 5 lutego 2020 r. Sąd Okręgowy w Hadze opisał SyRI jako ustawowe narzędzie rządowe służące do zwalczania nadużyć w świadczeniach, zasiłkach i podatkach. Sąd nie rozstrzygnął sprawy, pytając, ile parametrów miał system. Ocenił ramy prawne w świetle art. 8 Europejskiej Konwencji Praw Człowieka, w tym to, czy ingerencja w życie prywatne zachowywała słuszną równowagę.

Sąd uznał, że ustawodawstwo dotyczące SyRI nie przeszło tego testu. Według sądu korzystanie z SyRI było niewystarczająco przejrzyste i poddane kontroli. Ramy prawne były zatem niezgodne z prawem wyższego rzędu i nie mogły utrzymać się w dotychczasowej formie. Strona publiczna z wyrokiem jest zwięzła, ale jej lekcja nie jest mała: gdy państwo używa systemu wskazującego ryzyko wobec ludzi, którzy mogą mieć niewielką możliwość jego zrozumienia lub zakwestionowania, system wymaga poziomu wglądu i kontroli odpowiadającego tej relacji.

SyRI był niderlandzkim ustawowym instrumentem wskazywania ryzyka, a nie studium przypadku dotyczącym nowoczesnego modelu neuronowego, a strona sądu nie podaje nam liczby parametrów do omówienia. Właśnie dlatego należy on tutaj. Ten przykład zapobiega traktowaniu architektury modelu jako jedynego interesującego obiektu. Silnik reguł, karta oceny, model statystyczny lub mały klasyfikator mogą stać się częścią decyzji instytucjonalnej. Kwestia praw pojawia się poprzez użycie.

Wyrok umieszcza również przejrzystość we właściwym miejscu. Nie jest to jedynie prośba o wyjaśnienie po tym, jak osoba doznała szkody. Jest to część warunków, na jakich system może być oceniany przed rozpoczęciem działania i w trakcie jego trwania. Jeśli ludzie nie mogą zobaczyć wystarczająco dużo z celu, wykorzystania danych, zabezpieczeń i drogi odwołania, aby zrozumieć ingerencję, organizacja może nie być w stanie wykazać uczciwej równowagi, którą twierdzi, że osiągnęła.

Nie ma potrzeby przekształcać SyRI w uniwersalną analogię. Niderlandzkie ramy prawne, okoliczności sprawy i Konwencja Europejska są szczegółowe. Użyteczne przeniesienie jest węższe: nie pytaj, czy system jest technicznie imponujący, zanim nie zapytasz, czy jego relacja instytucjonalna jest widoczna, możliwa do kontrolowania i możliwa do zakwestionowania. Mniejsza maszyna nie usprawiedliwia większego milczenia.

Zastosowanie końcowe jest miejscem, gdzie wędruje etykieta

Model może zostać wprowadzony jako komponent, a mimo to stać się częścią systemu, który niesie inne zobowiązanie. Wytyczne Komisji dotyczące GPAI wyjaśniają, dlaczego dostawcy końcowi potrzebują informacji o możliwościach i ograniczeniach modelu. Potrzebują tych informacji, aby odpowiedzialnie zintegrować model i spełnić własne obowiązki wynikające z aktu o sztucznej inteligencji. Dostawca modelu i dostawca systemu nie piszą tego samego dokumentu, ponieważ nie odpowiadają na to samo pytanie.

To rozróżnienie ma znaczenie, gdy zespoły traktują kartę modelu jak paszport. Karta modelu może opisywać architekturę, szkolenie, ocenę, znane ograniczenia i zamierzone zastosowania. Sama w sobie nie może opisać każdego środowiska, w którym zespół końcowy może umieścić model. System końcowy dodaje użytkownika, cel, przepływy danych, interfejs, role ludzkie, decyzję i zestaw osób, których to dotyczy. Te dodatki mogą zmienić zobowiązanie, nawet gdy wagi modelu pozostają nietknięte.

Odpowiedzialność może się również zmienić, gdy organizacja modyfikuje zamierzony cel lub dokonuje istotnej modyfikacji. Przepisy aktu o sztucznej inteligencji dotyczące łańcucha wartości opisują okoliczności, w których podmiot może przyjąć obowiązki dostawcy, w tym zmianę zamierzonego celu systemu sztucznej inteligencji tak, aby stał się systemem wysokiego ryzyka. Jest to użyteczne ostrzeżenie przed zamętem umownym. Dostawca może dostarczyć komponent, ale wdrażający nie może sprawić, że jego własne użycie zniknie, nazywając komponent biblioteką.

Praktyczne przekazanie powinno zatem nieść więcej niż link do pobrania. Powinno określać zamierzone zadania, granice wejścia i wyjścia, wymagania integracyjne, informacje o szkoleniu i walidacji tam, gdzie istotne, znane ograniczenia oraz warunki, w których komponent nie powinien być używany. Powinno wyjaśniać, czego model nie ocenił. Zespół końcowy nie powinien musieć wnioskować o braku gwarancji z obecności pewnego siebie diagramu.

Istnieje ludzki powód tej dokumentacji. Osoba, której dotyczy końcowy system, nie spotyka dostawcy modelu w abstrakcie. Spotyka organizację, która wybrała przepływ pracy. Organizacja musi być w stanie powiedzieć, co zrobił komponent, co organizacja z nim zrobiła i jak osoba może zakwestionować wynik. Jeśli odpowiedzi znajdują się w trzech umowach i nie ma żadnego zapisu operacyjnego, system nie jest dobrze zintegrowany. Jest jedynie dobrze rozproszony.

Ludzka droga musi być realna

Nadzór człowieka bywa przedstawiany jako osoba siedząca przy ekranie. Akt o sztucznej inteligencji jest bardziej precyzyjny. W przypadku systemów wysokiego ryzyka nadzór musi być skuteczny i proporcjonalny do ryzyka, poziomu autonomii oraz kontekstu użycia. Osoba wyznaczona do nadzoru powinna rozumieć istotne możliwości i ograniczenia, monitorować nieprawidłowości, interpretować wyniki, decydować o ich niewykorzystaniu, ignorować je lub nadpisywać, cofać je oraz bezpiecznie interweniować lub zatrzymać system.

Żaden z tych czasowników nie jest zagwarantowany przez mały model. Wąski wynik może być łatwiejszy do interpretacji, ale interpretacja to nie to samo co władza. Przycisk nadpisania, którego nikt nie może użyć, bo kolejka jest zbyt długa, nie jest skutecznym nadzorem. Osoba sprawdzająca, która widzi tylko kolor lub etykietę, nie może w znaczący sposób zweryfikować źródła. Człowiek obwiniany za decyzję, ale niemogący wstrzymać przepływu pracy, nie jest punktem kontrolnym. Jest ozdobną luką w kształcie człowieka na diagramie.

Proporcjonalny nadzór może być dyskretny. Może to być czytelna ścieżka dla pracownika do oznaczenia niewystarczających dowodów, dodatkowa kontrola w przypadku wrażliwej kategorii, zapis przyczyn odrzucenia rekomendacji albo automatyczne wstrzymanie, gdy brakuje wymaganych pól. Może to być osoba, która jest właścicielem decyzji i ma czas na zbadanie przypadków, które system jej kieruje. Szczegóły zależą od kontekstu. Wymogiem jest, aby ścieżka działała, gdy system jest niepewny, błędny, niedostępny lub zakwestionowany.

W przypadku małych modeli strukturalna odmowa może być zaletą. Jeśli klasyfikator potrafi wskazać brakujące źródło, zakres poza kompetencjami lub potrzebę przeglądu, organizacja ma konkretne zdarzenie do obsłużenia. To lepsze niż płynny akapit, który po cichu zamienia niepewność w instrukcję. Odmowa nadal potrzebuje jednak właściciela. Jeśli każda odmowa staje się ślepą uliczką, system po prostu przeniósł ciężar na kogoś, nie dając mu ścieżki przez ten problem.

Ścieżka ludzka obejmuje także osobę, której dotyczy decyzja. Człowiek nie powinien potrzebować terminologii dostawcy, aby zakwestionować wynik. Organizacja powinna wiedzieć, jakie informacje można wyjaśnić, co można poprawić, kto rozpatruje sprawę i co się dzieje w trakcie przeglądu. Mały model może ułatwić opisanie wewnętrznego śladu. Nie zmniejsza to znaczenia osoby spoza systemu.

Proporcjonalne kontrole nadal są kontrolami

Proporcjonalne zarządzanie zaczyna się od odrzucenia dwóch złych układów. Pierwszy głosi, że każdy system zasługuje na ten sam ciężki proces, co zamienia zarządzanie ryzykiem w papierologię i w końcu uczy zespoły ukrywania pracy. Drugi głosi, że małe modele nie zasługują na żaden poważny proces, co myli wąski komponent z nieszkodliwą instytucją. Podejście proporcjonalne pyta, co system może zmienić, kogo może dotknąć i jakie dowody pozwoliłyby organizacji naprawić błąd.

Pierwszą kontrolą jest deklaracja celu zrozumiała dla niespecjalisty. Powinna określać zadanie, docelowych użytkowników, osoby, których dotyczy, dozwolone dane wejściowe, wynik oraz działania, których system nie może podjąć. Cel taki jak wsparcie priorytetyzacji jest zbyt niejasny, jeśli mógłby oznaczać układanie prywatnej kolejki, decydowanie o tym, kto otrzyma ustawową kontrolę, albo wybór kandydatów do postępowania dyscyplinarnego. To zdanie nie jest tekstem marketingowym. Jest granicą, względem której sprawdza się późniejsze zmiany.

Drugą kontrolą jest granica danych wejściowych i dowodów. Jakie źródła może czytać system. Które pola są wiążące. Jak aktualne muszą być. Co się dzieje, gdy wartość brakuje lub jest sprzeczna z innym źródłem. Czy dane osobowe mogą trafić na ścieżkę. Który zapis jest przechowywany. Kompaktowy model może być rygorystyczny co do danych wejściowych i nadal zawieść, jeśli otaczający przepływ pracy po cichu poszerza zakres danych. Zakres potrzebuje właściciela, nie tylko schematu.

Trzecim mechanizmem kontrolnym jest kontrakt wyjściowy. Określ dopuszczalne etykiety, stany niepewności, warunki odmowy oraz działania następcze dla każdego wyniku. Jeśli system zwraca wynik liczbowy, wyjaśnij, co ten wynik oznacza, a czego nie oznacza. Jeśli zwraca ranking, określ, czy ranking jest sugestią, czy bramką. Jeśli zwraca kategorię, wskaż, kto może ją zmienić i w jakim rejestrze odnotowuje się tę zmianę. Mały słownik jest użyteczny tylko wtedy, gdy instytucja zgadza się nie przemycać do niego dodatkowej władzy.

Czwartym mechanizmem kontrolnym jest ścieżka zmian. Aktualizacje modelu, zmiany progów, nowe źródła danych, inna grupa użytkowników, nowy dostawca lub zmienione działanie następcze mogą zmienić ryzyko związane z systemem. Język cyklu życia w Akcie o sztucznej inteligencji przypomina, że zarządzanie ryzykiem ma charakter iteracyjny. Komponent, który w styczniu był wąsko stosowany, w sierpniu może znaleźć się w innym procesie decyzyjnym. Obowiązek wynika ze zmienionej relacji, a nie z daty na pierwszym dokumencie projektowym.

Piątym mechanizmem kontrolnym jest wyjście. Czy organizacja może wstrzymać działanie komponentu, przejść na ścieżkę obsługi przez człowieka, wyeksportować rejestry, wyjaśnić historię decyzji i zmienić dostawcę bez utraty dowodów potrzebnych do naprawy spraw. Wyjście nie jest luksusem zarezerwowanym dla dużych systemów. Mały model może stać się jedynym nośnikiem pamięci instytucjonalnej, jeśli nikt nie zachowa źródła, wersji i ścieżki decyzyjnej wokół niego.

Proporcjonalny plik dowodowy

Proporcjonalny plik dowodowy nie jest magazynem wszystkich myśli, jakie ktokolwiek miał na temat modelu. To czytelna odpowiedź na pytania, które recenzent, operator, osoba zainteresowana lub organ regulacyjny może zasadnie zadać. Jaki był zamierzony cel. Która wersja działała. Jakie dane otrzymała. Co zwróciła. Która reguła lub próg przekształcił ten wynik w działanie. Kto miał uprawnienia do zmiany wyniku. Co się działo, gdy brakowało dowodów. Jak można odtworzyć decyzję lub ją zakwestionować.

W przypadku sugestii o niskich konsekwencjach plik może być niewielki. Może zawierać cel, źródło, wersję, podstawową ocenę, właściciela, zasadę przechowywania i link do ścieżki korekty. W przypadku systemu, który wpływa na dostęp, bezpieczeństwo, zatrudnienie lub prawa, plik musi być obszerniejszy. Powinien łączyć analizę ryzyka z danymi i kontraktem wyjściowym, pokazywać, jak nadzór człowieka działa w praktyce, dokumentować znane ograniczenia i zachowywać wystarczającą historię operacyjną, aby zbadać sporny wynik. Proporcjonalność rośnie wraz z konsekwencjami, a nie z liczbą parametrów.

Testowanie powinno kierować się tą samą logiką. Pojedyncza wartość dokładności nie może opisać przydatności systemu w każdym kontekście. Przetestuj wycinki danych i warunki, które mają znaczenie dla celu. Uwzględnij dane brakujące i sprzeczne. Uwzględnij przypadki, w których odmowa jest właściwa. Sprawdź, czy różne zespoły korzystają z wyników modelu w różny sposób. Zapisz, co mierzono, w jakich warunkach i co pozostaje nieznane. Model, który dobrze działa na czystym zestawie testowym, może być źle umiejscowiony w nieuporządkowanej instytucji.

Monitorowanie to nie ozdoba pulpitu. To sposób, w jaki organizacja dowiaduje się, że rzeczywisty przepływ pracy się zmienił. Obserwuj zmiany w danych wejściowych, wskaźniki niezgodności, wskaźniki odmów, zmiany w nadrzędnych decyzjach człowieka, nowe zastosowania następcze oraz skargi lub prośby o korektę. Dokładne sygnały zależą od systemu. Zasada jest stała: dowody powinny obejmować relację, która tworzy obowiązek, a nie tylko wewnętrzny wynik modelu.

Dobre dowody mają również datę ważności, nawet jeśli rejestry są przechowywane dłużej. Interpretacja prawna może się zmienić. Usługa może dotrzeć do nowej populacji. Dostawca może zaktualizować model. Ścieżka, która była odwracalna, może zostać wbudowana w inny system. Oznacz, co oceniono, kiedy, przez kogo i w odniesieniu do jakiego celu. Rejestr staje się wówczas historią decyzji, a nie statycznym certyfikatem, który przeżywa warunki, które czyniły go znaczącym.

Tryby awarii małych modeli

Małe systemy zawodzą w rozpoznawalny sposób. Klasyfikator może pominąć kategorię, ponieważ definicja etykiety jest niejednoznaczna. Ekstraktor może zwrócić prawdopodobne pole z niewłaściwego zdania. Model rankingowy może preferować znane przypadki i ukrywać te nietypowe. Próg może zamienić ciągłą niepewność w fałszywą dychotomię. Lokalny model może działać niezawodnie, podczas gdy dane źródłowe są nieaktualne. Żadna z tych awarii nie jest automatycznie katastrofalna. Każda staje się istotna, gdy przepływ pracy traktuje wynik jako bardziej autorytatywny, niż pozwala na to kontrakt komponentu.

Pierwszy rodzaj awarii to fałszywa skromność. Zespół twierdzi, że model tylko flaguje, sortuje lub wspomaga, a następnie projektuje przepływ pracy tak, aby pracownicy rzadko się sprzeciwiali. Etykieta staje się decyzją z przyzwyczajenia. To nie jest wada liczby parametrów modelu. To wada w sposobie, w jaki instytucja zarządza autorytetem. Lekarstwem jest uczynienie przekazania widocznym, mierzenie odstępstw i sprzeciwów oraz danie ludziom praktycznej ścieżki do zmiany wyniku.

Drugi to ukryta kompozycja. Mały model może znajdować się obok wyszukiwania, reguł, kolejki, rankingu i usługi powiadomień. Każdy komponent wygląda na ograniczony. Razem mogą stworzyć potężną ścieżkę decyzyjną. Przegląd ryzyka powinien podążać tą ścieżką od początku do końca. Które źródło wchodzi pierwsze. Która transformacja usuwa kontekst. Która etykieta wyzwala działanie. Który rekord przetrwa. Która osoba może zatrzymać łańcuch. Zapewnienie jakości na poziomie komponentu jest konieczne, ale nie jest to widok całego systemu.

Trzeci to nieaktualne zobowiązanie. Model pozostaje niezmieniony, podczas gdy jego cel lub odbiorcy się zmieniają. Zespół dodaje nowe źródło danych, wysyła wyniki do innego działu lub zaczyna używać prywatnego narzędzia priorytetyzacji w przepływie pracy skierowanym do odbiorców zewnętrznych. Karta modelu pozostaje taka sama, więc wszyscy zakładają, że ryzyko jest takie samo. Nie jest. Zamierzony cel się przesunął, a plik z dowodami powinien podążać za nim.

Czwarty to aureola małego modelu. Niski koszt zasobów lub schludne lokalne wdrożenie sprawiają, że system wydaje się bardziej odpowiedzialny, niż jest w rzeczywistości. Organizacja może nadal nie być w stanie wyjaśnić wyniku, zachować danych wejściowych, zapewnić środków naprawczych ani wyznaczyć osoby z uprawnieniami. Efektywność techniczna jest mile widziana. Nie zastępuje ona kontroli instytucjonalnej. System może być tani w utrzymaniu, a kosztowny w obronie.

Piąty to brak wyjścia. Małe komponenty łatwo dodać, a trudno usunąć, gdy wrosną w zajęty proces. Zastąpienie zmienia kategorie, progi lub rekordy, których oczekują zespoły downstream. Jeśli nikt nie przećwiczył zmiany, system staje się lepki. Model może być mały, ale migracja staje się teraz problemem publicznym. Przenośność powinna być częścią pierwszej rozmowy projektowej, a nie ostatniego spotkania zakupowego.

Kiedy mały rozmiar jest właściwym wyborem inżynieryjnym

Nic z tego nie powinno zamienić się w kampanię przeciwko małym modelom. Mały może być dokładnie tym, czego potrzeba. Wąskie zadanie z jasnym kontraktem może nie wymagać modelu ogólnego przeznaczenia. Lokalny komponent może utrzymywać wrażliwe dane bliżej osób za nie odpowiedzialnych. Stały wynik może ułatwić walidację i monitorowanie. Model, który odmawia działania poza swoim zakresem, może być bezpieczniejszy w kompozycji niż taki, który odpowiada na każde pytanie z wdzięczną pewnością.

Argument inżynieryjny jest najmocniejszy, gdy zespół potrafi nazwać, czego komponent nie będzie robił. Będzie klasyfikował tylko zatwierdzone kategorie. Będzie czytał tylko zadeklarowane pola. Zwróci niewystarczające dowody, gdy brakuje wymaganego pola. Nie wywoła narzędzia. Nie podejmie ostatecznej decyzji. Będzie nosić wersję i rekord ewaluacji. Będzie można go zastąpić, ponieważ interfejs i kontrakt dotyczący dowodów są udokumentowane. Te ograniczenia nie czynią systemu dziecinnym. Czynią jego obowiązki czytelnymi.

Małe komponenty mogą też wspierać lepszy podział pracy. Szeroki model potrafi interpretować nieuporządkowany język lub tworzyć czytelne dla człowieka wyjaśnienia. Ścisły komponent może wyodrębnić pole, zastosować bramkę polityki, uszeregować zadeklarowany zbiór źródeł albo sprawdzić, czy wynik spełnia znaną formę. Silnik reguł lub solver może odpowiadać za część, która musi być dokładna. Człowiek może odpowiadać za osąd, którego nie da się bezpiecznie zredukować. Najważniejszy nie jest puryzm. Chodzi o to, że każda część ma ograniczone zadanie, a system rejestruje, jak te zadania się łączą.

W tym układzie jest europejska praktyczność. Instytucje rzadko mogą wymienić wszystko naraz. Potrzebują systemów, które działają w warunkach sprzętowych, prawnych, językowych i zakupowych, jakie faktycznie mają. Mniejsze komponenty można czasem wdrożyć bliżej miejsca pracy, ocenić na podstawie lokalnych dowodów i wymienić bez konieczności zmiany pamięci całej organizacji. To oczekiwanie, a nie twierdzenie o każdym małym modelu. Wdrożenie nadal wymaga dowodu, że dopasowanie jest realne.

Małość jest też użyteczna jako dyscyplina. Gdy zespół nie może rozwiązać problemu, dodając więcej ogólnych możliwości, musi zdecydować, które informacje mają znaczenie, którą niepewność można ujawnić i które przypadki wymagają człowieka. Taka praca projektowa może ujawnić, że model w ogóle nie jest potrzebny. Czasem właściwym komponentem jest ograniczenie w bazie danych, indeks wyszukiwania, podpisany rekord albo dobrze napisany formularz. Mniejszy model może dźwigać dużą odpowiedzialność. Komponent niebędący modelem też może.

Gdy małość służy za kamuflaż

Małość staje się kamuflażem, gdy jest podawana jako odpowiedź, zanim ktokolwiek opisał pytanie. Oferta może mówić, że komponent jest lekki, lokalny, prywatny, wydajny lub otwarty. To wszystko mogą być przydatne fakty. Nie mówią one jednak osobie, której sprawa dotyczy, czy system można zakwestionować, ani operatorowi, czy wynik można odwrócić, ani regulatorowi, czy organizacja rozumiała swój cel.

Kamuflaż często pojawia się w języku zamówień publicznych. Kupujący widzi rozmiar modelu, wartość opóźnienia i koszt wnioskowania. Umowa mówi, że dostawca zapewnia narzędzie wspomagania decyzji. Nikt nie zapisuje, które decyzje, czyje dane, które populacje, jaka ścieżka ludzkiego udziału ani które zmiany uruchamiają przegląd. Później wewnętrzny zespół odkrywa, że narzędzie stało się bramką, bo kolejka, termin lub pulpit nawigacyjny sprawiły, że wygodnie było zastosować się do zalecenia. Model był mały. Zarządzanie było jeszcze mniejsze.

Innym kamuflażem jest zwrot człowiek w pętli. Osoba może technicznie dotykać każdego przypadku, nie mając jednak ani czasu, ani informacji, ani uprawnień, które miałyby znaczenie. Pętla działa wtedy jak rytuał zatwierdzania. Mały model może to czynić szczególnie kuszącym, bo wynik wygląda prosto. Pojawiają się trzy kategorie, osoba klika jedną, a organizacja nazywa wynik sprawdzonym. Przegląd wymaga zdolności do zrozumienia, zakwestionowania i zmiany wyniku. Kliknięcie samo w sobie nie jest zabezpieczeniem.

Trzeci kamuflaż to twierdzenie, że lokalność oznacza suwerenność. Przetwarzanie lokalne może pomóc w kwestii rezydencji danych, opóźnień i kontroli operacyjnej, ale suwerenność dotyczy też tego, kto może zmieniać oprogramowanie, trzymać klucze, uzyskiwać dostęp do rejestrów i utrzymywać usługę, gdy dostawca lub sieć jest niedostępna. Mały model w urządzeniu może być lokalny, podczas gdy jego aktualizacje, ocena i autorytet pozostają gdzie indziej. Lokalizacja to fakt na mapie. Kontrola to fakt w relacji.

Odtrutką nie jest większa forma. Jest nią forma ostrzejsza. Zapytaj o cel. Zapytaj, co zmienia się dzięki wynikowi. Zapytaj, kto może się nie zgodzić. Zapytaj, co może zrobić osoba, której sprawa dotyczy. Zapytaj, jakie dowody są przechowywane. Zapytaj, jak system jest wstrzymywany, wymieniany i ponownie oceniany. Jeśli odpowiedzi są jasne, rozmiar modelu może wrócić na właściwe miejsce jako jeden z wielu wyborów inżynieryjnych.

Pytania kupującego

Zanim mały model trafi do pracy o istotnych konsekwencjach, kupujący powinien umieć odpowiedzieć na ciąg prostych pytań. Jaki jest zamierzony cel w jednym zdaniu. Co jest poza zakresem. Które osoby mogą być dotknięte, bezpośrednio lub przez działanie w dalszym ciągu procesu. Które dane są wymagane, a które są zabronione. Na co każde wyjście pozwala organizacji. Na co jej nie pozwala.

Następnie należy zapytać o uprawnienia. Kto jest właścicielem decyzji. Kto może unieważnić model. Kto może zatrzymać proces. Jakie informacje widzi ta osoba. Ile ma czasu. Co się dzieje, gdy się nie zgadza. Czy osoba dotknięta decyzją otrzymuje wystarczające informacje, aby poprosić o weryfikację. Czy organizacja może poprawić zarówno dane wejściowe, jak i wyjściowe. Te pytania nie są oskarżeniem pod adresem dostawcy. Są minimalnym opisem instytucji kupującej narzędzie.

Zapytaj o dowody. Która wersja działała. Która konfiguracja modelu i zasad była aktywna. Które źródła były dostępne. Który próg lub reguła zamieniła wyjście w kolejne działanie. Co jest rejestrowane, gdy człowiek zmienia wynik. Czy organizacja może odtworzyć przypadek bez udawania, że nowe uruchomienie jest tym starym. Czy może wyeksportować zapisy w formie czytelnej dla innego systemu. Odpowiedź nie musi być wielką platformą. Musi być prawdziwym zapisem.

Zapytaj o zmiany. Co liczy się jako aktualizacja modelu. Co liczy się jako nowe źródło danych. Co się dzieje, gdy zmienia się cel. Które zmiany wymagają nowej oceny. Kto jest powiadamiany. Jak osoby dotknięte są chronione podczas wycofania lub migracji. Jeśli dostawca nie potrafi odpowiedzieć, kupujący nie nabywa małego ryzyka. Kupujący przyjmuje mały opis dużej niewiadomej.

Na koniec zapytaj o wyjście. Czy proces może działać bezpiecznie bez modelu. Czy organizacja może odzyskać dane wejściowe, wyjściowe, decyzje i historię poprawek. Czy inny komponent może spełnić ten sam interfejs bez nowej zależności. Czy system można wycofać bez pozostawiania ludzi w zawieszeniu. Model nie jest naprawdę mały, jeśli jego usunięcie wymaga od instytucji zapomnienia, jak podejmowała decyzje.

Krótka uwaga od nas

W Dweve Loom jest jednym z przykładów podejścia projektowego, które wnosimy do tego pytania. Jego publiczny opis produktu przedstawia małe komponenty językowe jako mechanizmy renderujące wokół typowanego grafu rozumowania, ze śladami, odtwarzaniem i wyraźnymi granicami odmowy. To stwierdzenie o naszej architekturze i o tym, jak chcemy, aby odpowiedzialność komponentu była widoczna. Nie jest to niezależny dowód, klasyfikacja regulacyjna, wdrożenie u klienta ani obietnica, że mały komponent jest automatycznie odpowiedni do zastosowania o istotnych konsekwencjach.

Użyteczną częścią przykładu jest granica. Komponent może być mały i nadal zasługiwać na precyzyjną umowę. Może być umieszczony w większym grafie bez stawania się właścicielem każdej decyzji. Może przenosić ślad bez twierdzenia, że ślad dowodzi, iż cała instytucja działała zgodnie z prawem. Wspominamy tu o Loom tylko po to, aby pokazać, jak nasza własna praca stara się oddzielić możliwości modelu, cel systemu, dowody i uprawnienia ludzi. Europejskie pytanie pozostaje dla nas takie samo jak dla każdego innego: co ten system może zmienić i czy osoby odpowiedzialne mogą go nadal kontrolować i poprawiać?

Obowiązek spoczywa na relacji

Mały model może być łatwiejszy do uruchomienia, łatwiejszy do przetestowania i łatwiejszy do zastąpienia. To dobre powody, aby go wybrać. Nie są to powody, aby pomniejszać otaczający obowiązek staranności. Definicje i zasady ryzyka w rozporządzeniu o sztucznej inteligencji, wytyczne Komisji dotyczące GPAI, podejście EDPB do danych w poszczególnych przypadkach oraz holenderski wyrok w sprawie SyRI wskazują w tym samym praktycznym kierunku, nie stając się jednym testem prawnym: należy patrzeć na cel, kontekst, uprawnienia, dowody, osoby dotknięte i możliwość dochodzenia roszczeń.

Właściwe pytanie nie brzmi zatem, czy model jest mały. Chodzi o to, co modelowi wolno zmieniać. Jeśli pomaga jedynie w przeszukiwaniu własnych notatek, odpowiedź może być skromna. Jeśli zmienia to, kto otrzymuje uwagę, który zapis jest uznawany za wiarygodny, albo czy usługa publiczna otwiera drzwi, odpowiedź jest poważniejsza. Jeśli organizacja nie potrafi wyjaśnić przekazania zadania, zachować dowodów ani zapewnić komuś drogi odwołania się od wyniku, obowiązek już przerósł sam komponent.

Dobre zarządzanie pozostawia miejsce na proporcjonalność. Nie wymaga, aby każdy model stał się komitetem. Prosi zespół o uwidocznienie ważnych zależności, powiązanie twierdzeń z dowodami i przyznanie ludziom realnej władzy, gdy system jest niepewny lub błędny. Małe modele mogą w tym pomóc, ponieważ ograniczony komponent można nazwać i przetestować. Ograniczenie jest jednak osiągnięciem projektowym, a nie domyślną cechą małości.

Rozmiar należy do dokumentacji technicznej. Cel należy do dokumentacji systemu. Konsekwencje należą do dokumentacji ludzkiej. Gdy te trzy dokumentacje mogą ze sobą rozmawiać, mały model można stosować ostrożnie, nie traktując go jako nieszkodliwego. Gdy są trzymane osobno, skromność modelu staje się teatrem, a ludzie ponoszący konsekwencje płacą za brakujący kontekst.

Źródła