Każda organizacja o pewnej wielkości ma już strukturę ryzyka. Komitet ryzyka, funkcję audytu, linię raportowania do zarządu, format, w którym ryzyka są klasyfikowane i śledzone. Kto obok tego stawia nowy proces, specjalnie dla AI, z własnym komitetem, własnym kalendarzem i własnym językiem, w ciągu roku otrzymuje proces, którego nikt już nie wypełnia. Nie dlatego, że AI uznaje się za nieważne, lecz dlatego, że druga struktura konkuruje z pierwszą o czas, uwagę i mandat. Istniejąca struktura wygrywa niemal zawsze, bo jest wbudowana w oceny, cykle funkcjonowania i agendy zarządu. Nowa struktura stoi poza tym.
Pytanie więc nie brzmi, jak zbudować strukturę governance dla AI. Pytanie brzmi, jak AI może otrzymać miejsce w strukturze, która już istnieje.
Większość struktur ryzyka zawiera już kilka stałych elementów: inwentaryzację ryzyka, która jest okresowo aktualizowana, klasyfikację według wagi i prawdopodobieństwa, właściciela dla każdego ryzyka, linię eskalacji do wyższego poziomu, gdy przekroczona zostaje granica, oraz raportowanie do zarządu w stałych momentach. To jest struktura, w którą AI musi się wpasować, nie obok niej.
Oznacza to, że zastosowanie AI nie powinno znajdować się w osobnym rejestrze AI, lecz jako pozycja ryzyka w istniejącym rejestrze, z tymi samymi polami co każde inne ryzyko: właściciel, waga, prawdopodobieństwo, mitygacja, data statusu. Klasyfikacja według poziomu ryzyka, jaka przypada na inwentaryzację użycia AI, musi łączyć się ze skalą już używaną dla ryzyka operacyjnego, nie z nową skalą wymyśloną wyłącznie dla AI. Kto przeczyta co CIO powinien wiedzieć o ryzyku AI, zauważy, że właśnie to połączenie jest tym, co często zawodzi: technicznie poprawny wynik ryzyka AI, którego nikt nie może porównać z resztą rejestru ryzyka.
Dwie rzeczy utrudniają wbudowanie. Pierwsza to język. Menedżerowie ryzyka pracują z pojęciami takimi jak wpływ, prawdopodobieństwo i środek mitygujący. Dostawcy AI i zespoły techniczne pracują z wersjami modeli, danymi treningowymi i metrykami wydajności. Zestaw governance napisany wyłącznie w języku technicznym nie jest czytany przez komitet ryzyka. Zestaw governance napisany wyłącznie w języku ryzyka nie jest wypełniany przez właściciela technicznego. Zestaw musi być czytelny w obu kierunkach: wystarczająco techniczny, aby się zgadzał, wystarczająco zarządowy, aby dotarł. Ta zasada powraca przy polityce AI, która jest czytana: dokument, który łączy się z tym, jak ludzie już czytają i podejmują decyzje, zamiast wymagać nowego sposobu czytania.
Drugą rzeczą jest tempo. Komitet ryzyka zbiera się w stałym cyklu, często kwartalnie lub miesięcznie. Użycie AI zmienia się szybciej: zespół zaczyna w tym tygodniu korzystać z nowego narzędzia, bez żadnego poprzedzającego spotkania. Zestaw governance nie może więc być zależny od cyklu spotkań, aby funkcjonować. Musi istnieć lżejszy mechanizm, który obsługuje odstępstwa między stałymi momentami, i który zostaje formalnie potwierdzony przy następnym cyklu. Jak ten mechanizm działa w praktyce, opisano przy ścieżkach eskalacji, które działają: trasa wystarczająco krótka, aby została użyta zanim zbierze się następny komitet kwartalny.
Zestaw governance, który łączy się z istniejącą strukturą ryzyka, zawiera w głównych liniach: pozycję inwentaryzacyjną dla każdego zastosowania AI z właścicielem i klasą ryzyka, powiązanie z istniejącą ścieżką eskalacji, tak aby odstępstwo nie zniknęło w osobnym kanale, oraz stałe miejsce w okresowym raportowaniu do zarządu. Nie jako osobny rozdział o AI, lecz jako wiersz w tabeli, którą zarząd już zna. Jak takie raportowanie może wyglądać bez wprowadzania nowego formatu, opisano przy jak uzyskać raport dla zarządu na jednej stronie wbudowany w to, co już krąży.
Treść samych zasad, co dokładnie podpada pod jaki poziom ryzyka i jakie terminy do tego przypadają, jest ustalona gdzie indziej i podlega zmianom; ta strona dotyczy mechanizmu, który daje tej treści miejsce w istniejącej strukturze, nie treści samych zasad.
Wbudowanie udaje się tylko wtedy, gdy inwentaryzacja jest najpierw poprawna. A jest poprawna tylko wtedy, gdy ludzie odważają się powiedzieć, co używają. Kto podczas wypełniania pozycji ryzyka czuje, że szczera odpowiedź prowadzi do notatki w ocenie, nie wypełnia jej szczerze. Zestaw governance musi więc od pierwszej wersji jasno komunikować, że celem jest przegląd, nie sankcja. Bez tego zobowiązania część użycia pozostaje poza obrazem, a powiązanie ze strukturą ryzyka jest budowane na niekompletnej liście. Co członek zarządu powinien o tym wiedzieć, zanim zacznie się pierwsza inwentaryzacja, opisano przy co członek zarządu powinien wiedzieć o ryzyku AI.
To wbudowanie dotyczy ryzyka, własności i raportowania: zapewnia, że to, co robi AI, jest widoczne i możliwe do zarządzania w ramach struktury, która już istnieje. Inne pytanie, które logicznie następuje po tym, gdy przegląd już istnieje, to co AI w ramach tej pracy może faktycznie przejąć. Skan pracy FTE TO AI wylicza dla każdego zadania, jaka część pracy może zostać przejęta przez AI, jako krok następny po tym, gdy strona governance jest już uporządkowana.
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.