Dokumentacja zamówień publicznych jest systemem zarządzania

Heather Grizzle, Novara Consulting Group

Streszczenie

Zarządzanie sztuczną inteligencją coraz częściej wyraża się poprzez polityki, komitety, zasady, rejestry i klasyfikacje ryzyka. Te struktury mają znaczenie. Jednak gdy instytucja publiczna faktycznie nabywa i wdraża system AI, zarządzanie musi w końcu przybrać formę znacznie mniej abstrakcyjną. Musi stać się dokumentacją.

Ktoś musi opisać, co system ma prawo robić. Ktoś musi zdecydować, jakie dowody są wystarczające, by poprzeć twierdzenia dostawcy. Ktoś musi zidentyfikować osoby, które mogą ponieść szkodę w razie awarii systemu. Ktoś musi określić, które awarie wymagają interwencji człowieka, które zmiany wymagają ponownej oceny, a które warunki wymagają zawieszenia działania systemu. Jeśli te decyzje nie zostaną udokumentowane przed wdrożeniem, polityka zarządzania AI nie naprawi tego zaniedbania. To dokumentacja postępowania zakupowego jest miejscem, w którym zasady instytucjonalne stają się zobowiązaniami operacyjnymi.

Zarządzanie w końcu musi dotrzeć do transakcji

Rozwiązanie awaryjne jest zabezpieczeniem tylko wtedy, gdy osoba, która go potrzebuje, faktycznie może z niego skorzystać.

Heather Grizzle

Organizacje budują coraz bardziej wyrafinowane struktury zarządzania AI. Ustanawiają zasady odpowiedzialnej AI, tworzą komitety przeglądowe, prowadzą rejestry i klasyfikują systemy według ryzyka. Przyjmują polityki wymagające sprawiedliwości, przejrzystości, odpowiedzialności, prywatności, dostępności i nadzoru ludzkiego. Następnie rozpoczyna się postępowanie zakupowe. Dostawca odpowiada na zapytanie ofertowe. Planowane są prezentacje produktu. Zbierana jest dokumentacja dostępności. Wypełniane są kwestionariusze bezpieczeństwa. Negocjowane są warunki prawne. Właściciele biznesowi opisują oczekiwane korzyści wydajnościowe. Technologia przechodzi przez ustanowione przez instytucję bramki kontrolne i wchodzi do użytku.

Istnienie tych bramek kontrolnych może budować znaczne zaufanie instytucjonalne, ale zaufanie to nie to samo co decyzja, którą można obronić. Kluczowe pytanie z zakresu zarządzania nie dotyczy jedynie tego, czy system przeszedł przez wymagany proces. Dotyczy tego, czy powstała dokumentacja zawiera dowody niezbędne do uzasadnienia konkretnego zatwierdzonego wdrożenia.

To rozróżnienie staje się szczególnie istotne, gdy AI pośredniczy w dostępie dla osób z niepełnosprawnościami. System może podsumowywać informacje, komunikować się z pacjentami, oceniać kandydatów, tłumaczyć język, generować materiały instruktażowe, nadawać priorytet sprawom, wspierać pracowników, uwierzytelniać użytkowników, odpowiadać na pytania lub, coraz częściej, działać w imieniu instytucji. W każdym z tych przypadków dostępność nie jest po prostu cechą interfejsu. Jest częścią architektury decyzyjnej. Osoba z niepełnosprawnością może zetknąć się z systemem inaczej niż populacja, dla której system był pierwotnie zaprojektowany, testowany lub walidowany, a awaria dostępności może zmienić informacje, które ta osoba otrzymuje, dostępne jej wybory, jej zdolność do reakcji lub interpretację jej zachowania przez instytucję. Dokumentacja postępowania zakupowego musi więc ustalić więcej niż to, czy dostępność została wzięta pod uwagę. Musi ustalić, co zostało uwzględnione, co zostało przetestowane, co pozostaje nieznane i co instytucja postanowiła zrobić z tą niepewnością.

Dokumentacja postępowania zakupowego jako instrument odpowiedzialności

Dokumentacja postępowania zakupowego jest często rozumiana głównie jako zapis administracyjny. W przypadku AI powinna być coraz częściej rozumiana jako instrument zarządzania. Dojrzała dokumentacja zakupu AI powinna umożliwić niezależnemu recenzentowi odtworzenie rozumowania instytucji bez polegania na pamięci instytucjonalnej osób, które uczestniczyły w zakupie. Oznacza to, że dokumentacja powinna odpowiadać na kilka pytań:

1. Do czego dokładnie zakupiono system?
2. Czego wyraźnie zabroniono mu robić?
3. Jakie populacje miały się z nim zetknąć?
4. Jakie dowody poparły twierdzenia, na których opierano się podczas zatwierdzania, i kto je przedstawił?
5. Jakie ograniczenia były znane, a jakie pozostały nieznane?
6. Co się działo, gdy system był niepewny lub się mylił?
7. Kto zachował uprawnienia do jego uchylenia?
8. W jaki sposób osoba dotknięta skutkami mogła zakwestionować jego wynik?
9. Co skłoniłoby instytucję do ponownego rozważenia wdrożenia?
10. Kto miał uprawnienia, by go zatrzymać?

Nie są to pytania na potrzeby dochodzenia powypadkowego po awarii. To pytania dotyczące postępowania zakupowego.

1. Przeznaczenie i zabronione zastosowania

Pierwszy wymóg jest pozornie prosty: określić, co instytucja kupuje. Systemy AI są często nabywane na podstawie szerokich opisów możliwości. System może być opisany jako asystent, tłumacz, narzędzie dostępności, system wspomagania decyzji, chatbot, agent, narzędzie przesiewowe lub platforma produktywności. Te etykiety stanowią niewystarczającą specyfikację z punktu widzenia zarządzania. Dokumentacja postępowania zakupowego powinna określać rzeczywistą funkcję instytucjonalną.

Narzędzie komunikacyjne używane do pomocy w poruszaniu się po stronie internetowej stwarza inne ryzyko niż ta sama technologia użyta podczas wywiadu medycznego. Zautomatyzowany system transkrypcji używany do tworzenia notatek ze spotkań stwarza inne ryzyko niż ten sam system użyty do stworzenia oficjalnego zapisu postępowania dyscyplinarnego. System rozpoznawania języka migowego używany eksperymentalnie przez jednostkę nie jest równoważny systemowi, który instytucja przedstawia jako substytut innego środka dostępu do komunikacji. Ta sama technologia może więc przechodzić między kategoriami ryzyka bez żadnej zmiany w swoim podstawowym modelu, ponieważ zmienił się kontekst wdrożenia.

2. Analiza populacji dotkniętych skutkami

Tradycyjne postępowanie zakupowe dotyczące technologii pyta, kto będzie używał systemu. Zarządzanie AI musi również pytać, kto zostanie dotknięty jego skutkami, a te populacje niekoniecznie są takie same. Pracownik może obsługiwać system AI, podczas gdy pacjent, student, kandydat, mieszkaniec, klient lub beneficjent świadczeń doświadcza jego konsekwencji. Osoby z niepełnosprawnościami mogą być szczególnie trudne do zidentyfikowania w ramach konwencjonalnej analizy użytkowników, ponieważ niepełnosprawność często zmienia ścieżkę przechodzenia przez system, a nie nominalną kategorię użytkownika.

Dokumentacja postępowania zakupowego powinna zatem identyfikować przewidywalne interakcje związane z dostępnością. Czy system przetwarza mowę? Czy generuje lub interpretuje język? Czy zależy od wzroku, słuchu, sprawności manualnej, funkcji poznawczych, czasu reakcji, cech biometrycznych lub konkretnego sposobu komunikacji? Czy wnioskuje o intencji lub kompetencji na podstawie zachowania, na które może wpływać niepełnosprawność? Czy niedostępny wynik zmienia zdolność danej osoby do udziału w kolejnej decyzji? Te pytania przekształcają dostępność z artefaktu zgodności w badanie ryzyka systemowego.

3. Rejestr twierdzeń dostawcy

Każde istotne twierdzenie dostawcy, na którym opierano się podczas postępowania zakupowego, powinno mieć określony status dowodowy. Nie każde twierdzenie wymaga niezależnego testowania, ale instytucje powinny rozróżniać co najmniej trzy kategorie. Możliwość jest zadeklarowana, gdy dostawca stwierdza, że istnieje. Jest wykazana, gdy dowody pokazują, że została zaobserwowana w określonych warunkach. Jest potwierdzona do wdrożenia, gdy dowody rozsądnie uzasadniają poleganie na niej w zamierzonym kontekście instytucji. Te kategorie nie są wymienne.

Demonstracja może wykazać, że system jest w stanie wygenerować dany wynik. Niekoniecznie wykazuje, jak niezawodnie generuje ten wynik w różnych populacjach, środowiskach czy istotnych przypadkach użycia. Podobnie dokumentacja może ustalić, co dostawca twierdzi o swoim systemie. Nie może samodzielnie ustalić, że to twierdzenie jest prawdziwe. Dokumentacja postępowania zakupowego powinna zachować to rozróżnienie. W przeciwnym razie twierdzenia stopniowo stają się ustaleniami tylko dlatego, że zostały powtórzone w wystarczającej liczbie dokumentów.

Potwierdzone do wdrożenia

Status twierdzenia dostawcy oznaczający, że dowody rozsądnie uzasadniają poleganie na danej możliwości w rzeczywistym, zamierzonym kontekście instytucji, a nie jedynie to, że możliwość ta została zaobserwowana w warunkach demonstracyjnych.

4. Niezależne zapewnienie jakości

Dowody dostarczane przez dostawcę odgrywają uzasadnioną rolę w postępowaniu zakupowym. Dostawcy znają swoje systemy lepiej niż nabywcy i powinno się od nich oczekiwać ujawnienia testów, architektury, ograniczeń, znanych warunków awarii oraz odpowiednich dowodów skuteczności działania. Ale relacja handlowa ma znaczenie. Strona ubiegająca się o kontrakt nie powinna być jedyną stroną decydującą o tym, czy dowody są wystarczające, by go przyznać.

Niezależne zapewnienie jakości nie oznacza odtwarzania programu inżynieryjnego dostawcy. Oznacza testowanie twierdzeń istotnych dla decyzji zakupowej w warunkach zdolnych je obalić. W przypadku AI związanej z dostępnością może to wymagać oceny z udziałem osób z odpowiednią niepełnosprawnością, a w przypadkach dotyczących dostępu językowego — wykwalifikowanych członków danej społeczności językowej. Celem nie jest uczestnictwo ceremonialne. Celem jest autorytet dowodowy. Osoby zdolne zidentyfikować istotną awarię muszą dysponować mechanizmem, który pozwoli tej awarii wpłynąć na decyzję zakupową. W przeciwnym razie uczestnictwo istnieje bez zarządzania.

5. Awarie i architektura rozwiązań awaryjnych

Każde zamówienie dotyczące sztucznej inteligencji powinno zawierać pisemną odpowiedź na jedno pytanie: co się dzieje, gdy system nie działa? „Człowiek w pętli” nie jest wystarczającą odpowiedzią. Dokumentacja powinna wskazywać osobę odpowiedzialną, czynnik wyzwalający, zakres uprawnień, czas reakcji oraz alternatywną ścieżkę dostępną dla osoby, której to dotyczy.

W przypadku użytkowników z niepełnosprawnościami sam mechanizm zastępczy również musi być dostępny. System komunikacji oparty na AI, który ulega awarii i kieruje osobę Deaf do wykonania połączenia telefonicznego, nie zapewnił żadnego rozwiązania zastępczego. Zautomatyzowany proces cyfrowy, który staje się niedostępny i wymaga od niewidomego użytkownika ukończenia tego samego niedostępnego interfejsu, w żaden sensowny sposób nie przekazał tej osoby pod nadzór człowieka.

Rozwiązanie awaryjne jest zabezpieczeniem tylko wtedy, gdy osoba, która go potrzebuje, faktycznie może z niego skorzystać.

Heather Grizzle

6. Granice wydajności i znane niewiadome

Dokumenty zamówieniowe zwykle odnotowują, co produkty potrafią zrobić. Dokumentacja zarządcza musi też wskazywać, gdzie kończy się pewność. Wydajność AI jest warunkowa. Może się różnić w zależności od języka, dialektu, akcentu, stylu migania, oświetlenia, pozycji kamery, niepełnosprawności, urządzenia, środowiska, terminologii branżowej, długości interakcji, cech demograficznych i niezliczonych innych zmiennych. Instytucje powinny wymagać od dostawców ujawnienia znanych granic wydajności oraz oddzielnie udokumentować obszary, które nie zostały ocenione.

To rozróżnienie ma znaczenie. „Nieocenione” to nie to samo co „zawiodło”, ale też nie to samo co „bezpieczne”. Niepewność nie jest wadą zamówienia, jeśli zostanie rozpoznana i objęta nadzorem. Niepewność nieudokumentowana – owszem.

7. Rejestrowanie, identyfikowalność i rekonstrukcja

Gdy interakcja za pośrednictwem AI powoduje szkodę, instytucja powinna być w stanie zrekonstruować, co się wydarzyło, a to wymaga podjęcia decyzji dotyczących rejestrowania danych przed wdrożeniem. Jaka wersja systemu działała? Jakie dane wejściowe zostały otrzymane? Jaki wynik został wygenerowany? Czy wynik został zmodyfikowany? Czy człowiek go zweryfikował? Jakie informacje widział ten recenzent? Jakie działanie nastąpiło? Czy instytucja może odtworzyć zdarzenie bez przechowywania danych, które w ogóle nie powinny były być przechowywane?

Identyfikowalność i prywatność mogą tworzyć uzasadnione, konkurujące ze sobą wymagania. Ten konflikt powinien zostać rozwiązany poprzez projekt systemu i zarządzanie, a nie odkryty podczas postępowania sądowego, skargi dotyczącej dostępności czy wewnętrznego dochodzenia. Dokumentacja zamówienia powinna odnotowywać przyjęte rozwiązanie.

8. Skargi, możliwość kwestionowania i naprawa szkód

Osoba dotknięta działaniem AI potrzebuje czegoś więcej niż mechanizmu zgłaszania problemu technicznego. Może potrzebować zakwestionować to, co instytucja zrobiła z powodu działania systemu, a to jest inna funkcja. Jeśli system AI błędnie tłumaczy komunikację, nieprawidłowo charakteryzuje zachowanie, generuje niedostępne informacje, tworzy fałszywy wniosek lub przyczynia się do niekorzystnej decyzji instytucjonalnej, osoba dotknięta potrzebuje ścieżki umożliwiającej zakwestionowanie wynikającej z tego decyzji.

Instytucja powinna wiedzieć jeszcze przed wdrożeniem, kto przyjmuje odwołanie, kto je rozpatruje, jakie dowody są zachowywane, czy kwestionowany wynik AI pozostaje w użyciu w trakcie rozpatrywania, jakie środki zaradcze są dostępne i jak szybko instytucja musi zareagować.

9. Zmiana modelu i ponowna walidacja

Zamówienia dotyczące AI stwarzają problem, z którym tradycyjne umowy na oprogramowanie nie radzą sobie szczególnie dobrze: produkt, który został oceniony, może nie być już produktem, który jest wdrożony. Modele są aktualizowane. Mechanizmy zabezpieczające się zmieniają. Dane treningowe się zmieniają. Interfejsy się zmieniają. Zależności od podmiotów trzecich się zmieniają. Dostawcy zastępują modele bazowe. Wydajność może poprawić się w jednej dziedzinie, a pogorszyć w innej, bez jakiejkolwiek inicjatywy ze strony instytucji zamawiającej.

Dokumentacja zamówienia potrzebuje więc zasady kontroli zmian. Istotne pytanie nie dotyczy tego, czy dostawca ma prawo aktualizować swój produkt. Chodzi o to, które zmiany unieważniają dowody, na których opierała się instytucja. Umowy powinny wskazywać istotne zmiany wymagające powiadomienia, ponownej oceny, odnowionych testów akceptacyjnych lub zatwierdzenia przed dalszym użyciem w określonych kontekstach. W przeciwnym razie instytucja może przeprowadzić rygorystyczną weryfikację w momencie zakupu, a mimo to sześć miesięcy później znaleźć się w sytuacji zarządzania istotnie innym systemem, posługując się dowodami wytworzonymi dla poprzedniej jego wersji.

10. Uprawnienia do zawieszenia i wycofania

Zarządzanie bez uprawnienia do wstrzymania działania ma charakter wyłącznie doradczy. Ktoś w instytucji musi posiadać uprawnienia do ograniczenia, zawieszenia lub zakończenia wdrożenia AI, gdy dowody przestają uzasadniać jego stosowanie, a warunki wyzwalające takie działanie nie powinny być wymyślane dopiero w trakcie kryzysu.

Dokumentacja zamówienia powinna wskazywać zarówno czynniki wyzwalające, jak i osobę decyzyjną.

Powinna też odnosić się do zakończenia współpracy. Kto jest właścicielem danych instytucjonalnych lub je otrzymuje po zakończeniu relacji? Jakie zapisy muszą zostać zachowane? Co musi zostać usunięte? Jak instytucja przywraca poprzednią ścieżkę świadczenia usługi? Co dzieje się z osobami, które stały się zależne od procesu realizowanego za pośrednictwem AI? Planowanie wyjścia to nie tylko zarządzanie dostawcą. To planowanie ciągłości dostępu.

Od polityki AI do dowodów instytucjonalnych

Nowo pojawiającym się wyzwaniem w zarządzaniu AI nie jest brak zasad. Jest nim przełożenie ich na praktykę. Sprawiedliwość musi stać się kryterium oceny. Przejrzystość musi stać się wymogiem ujawniania informacji. Nadzór ludzki musi stać się przypisanym uprawnieniem. Dostępność musi stać się warunkiem wdrożenia. Odpowiedzialność musi stać się konkretnym stanowiskiem i udokumentowanym środkiem zaradczym. Monitorowanie musi stać się czynnikiem wyzwalającym działanie. A odpowiedzialna AI musi w końcu stać się czymś, co urzędnik ds. zamówień może umieścić w aktach.

Ma to szczególne znaczenie w instytucjach publicznych, ponieważ zamówienia to miejsce, w którym abstrakcyjne zobowiązania instytucjonalne spotykają się z pieniędzmi, umowami, dostawcami, obowiązkami ustawowymi oraz ludźmi, którzy nie mogą po prostu wybrać innego rządu, szkoły, szpitala, sądu czy usługi publicznej, gdy technologia im nie służy. Dokumentacja zamówienia pełni więc funkcję znacznie większą niż prowadzenie ewidencji. Ustanawia teorię akceptowalnego ryzyka danej instytucji.

Stanowisko polityczne NCG

Novara Consulting Group stoi na stanowisku, że systemy AI wpływające na osoby z niepełnosprawnościami nie powinny być zatwierdzane wyłącznie dlatego, że spełniły ogólny proces zarządzania AI danej organizacji. Dokumentacja zamówienia powinna zawierać wystarczające dowody, by zrekonstruować i obronić konkretną decyzję o wdrożeniu.

Standardem nie jest doskonała wiedza. Żaden proces zakupowy nie jest w stanie wyeliminować niepewności. Standardem jest niepewność poddana zarządzaniu: wiedza o tym, co zostało ustalone, co nie zostało ustalone, jakie dowody uzasadniały mimo to podjęcie działania oraz kto ponosi odpowiedzialność za tę decyzję.

Stanowisko końcowe

Po awarii systemu AI instytucje często zadają pytanie, czy dostawca powinien był ostrzec. Czasem odpowiedź brzmi: tak. Ale rozliczalność publiczna wymaga innego pytania: jakich dowodów zażądała instytucja, zanim zgodziła się działać? Tego pytania nie można zlecić na zewnątrz. Dostawca może dostarczyć dowody. Oceniający może je zweryfikować. Komitet może doradzić. Zainteresowane strony z niepełnosprawnościami mogą wskazać błędy niewidoczne dla innych. Prawnicy mogą wynegocjować podział ryzyka umownego. Decyzję wciąż podejmuje instytucja, a jej dokumentacja zakupowa powinna dowodzić, że wiedziała, jaką decyzję podejmuje.

System AI nie jest nadzorowany dlatego, że organizacja posiada politykę AI. Jest nadzorowany, gdy instytucja potrafi wykazać, dlaczego temu systemowi, w tym celu, wpływającemu na te osoby, w tych warunkach, zezwolono na działanie.

Heather Grizzle

Dokumentacja zakupowa to miejsce, w którym ta rozliczalność się zaczyna.