Często już istnieje dokument zatytułowany procedura eskalacji. Zawiera schemat ze strzałkami, rząd nazwisk i kilka wartości progowych. Problem nie polega na tym, że dokument nie istnieje. Problem polega na tym, że nikt go nie otwiera w momencie, gdy jest potrzebny.
Nie dzieje się to z niechęci. Dzieje się to, ponieważ istnieje już ścieżka, wzdłuż której problemy wędrują do góry: kierownik liniowy, który zgłasza incydent IT, compliance officer, który rozmawia z biznesem, teamleader, który przekazuje swój problem swojemu własnemu przełożonemu. Ta ścieżka istnieje, jest używana codziennie i działa — dla rzeczy, do których jest przeznaczona. Nowa ścieżka eskalacji specjalnie dla incydentów AI staje się wtedy drugą trasą obok trasy, która już funkcjonuje. W razie wątpliwości każdy wybiera trasę, którą znają.
Ścieżka eskalacji, która stoi osobno od istniejącej struktury, wymaga od pracownika, aby najpierw rozpoznał, że coś jest incydentem AI, potem zapamiętał, że obowiązuje dla tego inny proces, a następnie zadał sobie trud, aby ten proces zastosować, zamiast po prostu zadzwonić do swojego przełożonego. Każdy krok w tym łańcuchu jest momentem, w którym ścieżka zostaje opuszczona.
Do tego dochodzi drugi powód, mniej widoczny, ale równie decydujący: ten, kto zgłasza odstępstwo, nie chce natychmiast figurować na formularzu incydentów organizacji. Jeśli eskalowanie jest równoznaczne z rozliczeniem, nikt nie eskaluje. Dotyczy to pracownika, który korzystał z narzędzia AI, które nie zostało zatwierdzone, i dotyczy to menedżera, który uruchomił model, o czym nikt nie wiedział. Ścieżka eskalacji, która jest faktycznie używana, to ścieżka, w której pierwsze zgłoszenie nie jest oceną, lecz sygnałem.
Ścieżka eskalacji, która działa, opisuje trzy rzeczy — i nie więcej.
Osoba, która coś zauważa — pracownik, klient, strona zewnętrzna — musi wiedzieć, do kogo może się zwrócić, bez konieczności wcześniejszego ustalania, czy jest to kwestia dotycząca AI, czy zwykła kwestia operacyjna. Ścieżka nawiązuje do już istniejącego punktu zgłoszeniowego, z dodatkową rozgałęzieniem w momencie, gdy okazuje się, że jest w to zaangażowana AI.
Osoba, która podejmuje decyzję — czy coś zostaje zatrzymane, dostosowane, czy zgłoszone organowi nadzorczemu — musi być ustalona zanim incydent się wydarzy. Nie jako abstrakcyjny tytuł funkcji, lecz jako nazwisko, wraz z zastępcą. Eskalacja, która grzęźnie przy pustym mandacie, nie jest eskalacją.
Co dzieje się później z osobą zgłaszającą, musi być jasne. Jeśli drugi proces składa się jedynie z obowiązku zgłoszenia bez jasności co do konsekwencji dla zgłaszającego, jest omijany. Właśnie tam kryje się cień-AI: nie w systemach, które znajomy jest IT, lecz w narzędziach, które ktoś zaczął używać bez zgłaszania tego, ponieważ zgłoszenie sprawiało wrażenie przyznania się.
Rozwiązaniem nie jest grubszy dokument. Jest to ścieżka eskalacji, która wykorzystuje strukturę, która już istnieje — punkt zgłoszeniowy, linię eskalacji, komitet ryzyka — i dodaje do niej rozgałęzienie specyficzne dla AI w punktach, w których robi to różnicę. Jak dokładnie działa to dopasowanie, także w odniesieniu do szerszej polityki i listy decyzji organu nadzorczego, opisano w jak uzyskać politykę AI, która jest czytana, ponieważ jest wpleciona w to, co już istnieje oraz w jak uzyskać listę decyzji nadzorczych, która nawiązuje do istniejącego rytmu podejmowania decyzji. Oba dokumenty dotyczą tego samego punktu: proces, który stoi obok organizacji, jest ignorowany; proces, który leży w niej samej, jest przestrzegany.
Ta zasada nie dotyczy tylko eskalacji. Dotyczy całej struktury governance wokół AI. Kto chce wiedzieć, jak to wygląda w szerszym ujęciu — jak klasyfikacja ryzyka nawiązuje do istniejących kategorii ryzyka, jak dopasowanie do istniejącej struktury ryzyka zapobiega powstaniu równoległej biurokracji — znajdzie tam podstawową zasadę. To samo dotyczy raportowania w górę: raport dla zarządu na jednej stronie działa tylko wtedy, gdy eskalacje, które w nim figurują, zostały rzeczywiście zgłoszone. A bez ciągłej obserwacji tego, co się zmienia, każda ścieżka eskalacji starzeje się w ciągu roku; co to oznacza w praktyce, wyjaśniono na monitoring, który przynosi rezultaty.
Ścieżkę eskalacji można napisać dopiero wtedy, gdy wiadomo, co może eskalować. Dopóki nikt nie wie, jaka AI działa w organizacji — w tym co nie zostało zatwierdzone — dokument pozostaje teoretyczny. Responsible AI Scan nie zaczyna się więc od ścieżki eskalacji, lecz od inwentaryzacji: co działa, kto to używa i jaki poziom ryzyka do tego przystaje. Tylko na tej podstawie można napisać ścieżkę eskalacji, która nawiązuje do tego, co już istnieje, a nie do tego, co powinno istnieć na papierze.
Ścieżki eskalacji dotyczą tego, co idzie źle z AI, która jest już używana. Inne pytanie, równie niedocenione, dotyczy tego, gdzie AI mogłaby przejąć samą pracę. Skan pracy FTE TO AI wylicza dla każdego zadania, jaka część pracy się do tego kwalifikuje, niezależnie od tego, czy to już się dzieje, czy jeszcze trzeba to zorganizować.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.