Jak osadzić listę decyzji nadzorczych w tym, co już istnieje

Lista decyzji nadzorczych rejestruje, kto podjął jaką decyzję o jakim systemie AI, na podstawie jakich informacji i z jakim zastrzeżeniem. Brzmi to prosto. W praktyce pierwsza wersja często kończy się niepowodzeniem, ponieważ jest wprowadzana jako nowy proces obok istniejących spotkań. Drugi proces obok istniejącego jest ignorowany, nie dlatego, że ludzie są niechętni, ale dlatego, że nikt nie rezerwuje czasu na coś, co nie wpisuje się w agendę, która jest już pełna.

Co powinno znajdować się na liście decyzji

Lista nie jest dziennikiem czynności ani rejestrem ryzyka. Zawiera decyzje: momenty, w których osoba posiadająca uprawnienia coś zatwierdziła, odrzuciła, odłożyła lub zezwoliła na kontynuację pod pewnymi warunkami. Każdy wiersz powinien zawierać co najmniej cztery elementy: system lub zastosowanie, którego dotyczy decyzja, imię, nazwisko i rolę osoby podejmującej decyzję, datę oraz uzasadnienie lub zastrzeżenie. Bez uzasadnienia lista decyzji jest listą obecności. Z uzasadnieniem staje się dowodem, że coś przemyślano, a nie tylko odhaczono.

Lista powinna również dawać miejsce na ponowne rozpatrzenie. Decyzja podjęta pół roku temu na podstawie wówczas dostępnych informacji może być już nieaktualna. Dobra lista decyzji pokazuje, kiedy decyzja została ponownie potwierdzona lub wycofana, nie tylko kiedy została pierwotnie podjęta.

Dlaczego odrębny proces jest ignorowany

Zarządy i dyrekcje mają już swój rytm: kwartalne posiedzenia, komitety ryzyka, komisje audytu. Kto wprowadza nową strukturę nadzoru oderwaną od tego rytmu, prosi ludzi o znalezienie dodatkowego czasu na coś, co nie ma jasnego miejsca. To rzadko dzieje się w sposób strukturalny. Kilka pierwszych razy może się udać, z wysiłkiem. Potem znika z agendy, gdy pojawi się coś bardziej naglącego, a coś bardziej naglącego pojawia się zawsze.

Rozwiązaniem nie jest budowanie nowego procesu, lecz osadzenie listy decyzji w tym, co już się dzieje. Jeśli istnieje już komitet ryzyka, który zbiera się co kwartał, lista decyzji dotyczących AI powinna być stałym elementem tej agendy, nie odrębną sesją. Jeśli istnieje już ścieżka audytu dla decyzji finansowych, logika tej ścieżki — kto podpisuje, kto kontroluje, gdzie jest przechowywana — powinna zostać ponownie wykorzystana dla decyzji dotyczących AI. To jest również powód, dla którego dopasowanie do istniejącej struktury ryzyka jest odrębnym tematem: lista decyzji, która nie łączy się z tym, jak ryzyko jest już omawiane w innych miejscach, pozostaje odizolowanym dokumentem, do którego nikt nie zagląda.

Związek z raportowaniem i eskalacją

Lista decyzji nie funkcjonuje samodzielnie. Zasila raportowanie, którego zarząd potrzebuje, aby móc powiedzieć, że ma wgląd w ryzyko związane z AI, i zakłada istnienie ścieżki na wypadek, gdyby decyzja okazała się już nieodpowiednia. Bez raportu dla zarządu na jednej stronie, który podsumowuje listę decyzji, informacja przepada w archiwum, którego nikt nie przegląda. Bez ścieżek eskalacji, które działają, decyzja, która jest już nieaktualna, po prostu pozostaje, ponieważ nikt nie wie, u kogo należy to zgłosić.

Te trzy elementy są ze sobą powiązane: lista decyzji rejestruje, co zostało postanowione, raportowanie sprawia, że jest to widoczne na poziomie, na którym ma znaczenie, a eskalacja zapewnia, że decyzja może zostać ponownie otwarta, gdy sytuacja się zmieni. Jeśli zbudujesz jeden element bez pozostałych dwóch, powstaje pozór przejrzystości, który przy pierwszym sprawdzeniu — incydencie, pytaniu organu nadzorczego, dziennikarza — nie pokrywa tego, co naprawdę się dzieje.

Kto wypełnia listę

Lista decyzji jest tak dobra, jak informacje, które się w niej znajdują. Jeśli nikt nie wie, jakie systemy AI są faktycznie w użyciu — łącznie z tym, co zostało nabyte lub wdrożone poza działem IT — lista rejestruje tylko decyzje dotyczące widocznych, formalnie zatwierdzonych zastosowań. Pozostałe pozostają bez decyzji, nie dlatego, że decyzja nie była potrzebna, ale dlatego, że nikt nie wiedział, że jest coś, o czym należało zadecydować. To jest powód, dla którego inwentaryzacja zawsze poprzedza listę decyzji, a nie następuje po niej. To, co powinien o tym wiedzieć członek zarządu, opisano w co powinien wiedzieć członek zarządu o ryzyku AI; to, co CIO powinien rozpoznać w tej inwentaryzacji, opisano w co powinien wiedzieć CIO o ryzyku AI.

Co jest pewne, a co zależy od organizacji

Co jest pewne: lista decyzji niepowiązana z istniejącym spotkaniem nie jest utrzymywana, a lista decyzji bez pełnego obrazu tego, co faktycznie działa, rejestruje tylko część rzeczywistości. Co zależy od organizacji: które spotkanie jest właściwym punktem zakotwiczenia, jak często to spotkanie się odbywa i kto ma uprawnienia do podjęcia decyzji, która trafia na listę. Różni się to w zależności od sektora, struktury zarządzania i kultury ryzyka, dlatego nie istnieje jeden stały szablon, który działa wszędzie bez modyfikacji.

Responsible AI Scan jest w budowie. Kto obecnie potrzebuje listy decyzji dopasowanej do istniejącej struktury, może zapisać się na listę oczekujących; nie oferuje się jeszcze niczego, czego jeszcze nie ma.