Zarząd, który stawia AI na agendzie, otrzymuje zwykle dwa rodzaje dokumentów: obszerne dossier, którego nikt nie przeczyta przed posiedzeniem, albo podsumowanie tak ubogie w treść, że nie wynika z niego żadna decyzja. Raport zarządu na jedną stronę nie jest podsumowaniem dossier. To inne pytanie: co musi wiedzieć członek zarządu, aby móc wziąć odpowiedzialność, a co jest szumem.
To rozróżnienie nie jest trywialne. Większość raportów dotyczących AI, które widzimy, po prostu liczy systemy. Strona, która liczy tylko, ile jest zastosowań AI, nie mówi zarządowi niczego o tym, gdzie leży ryzyko. Liczenie to pytanie z zakresu IT. Governance to inne pytanie: które zastosowania dotykają decyzji o ludziach, które zostały wdrożone bez nadzoru, i które podpadają pod klasę ryzyka wymagającą podpisu.
Działająca strona zawiera ograniczoną liczbę elementów, każdy z powodem, dla którego został uwzględniony:
Reszta — kto wytrenował jaki model, jaki dostawca stosuje jakie warunki, jakie zastosowano techniczne środki ograniczające ryzyko — należy do warstwy poniżej. Ta warstwa istnieje, jest prowadzona i można ją wywołać na żądanie. Ale nie należy do strony, którą czyta zarząd, bo wtedy zarząd jej nie przeczyta.
Powód, dla którego tak wiele procesów governance AI się zatrzymuje, nie jest brak procesu. Jest to, że istnieje drugi proces, obok istniejącego. Zarząd ma już komitet ryzyka, ma już kalendarz audytów, ma już format raportowania dotyczący ryzyka operacyjnego, zgodności, bezpieczeństwa informacji. Kto stawia obok tego osobny proces dotyczący AI — z własną częstotliwością, własnym szablonem, własnym właścicielem — prosi o coś, co pierwsze zostanie pominięte, gdy agenda jest zbyt pełna. Nie dzieje się to ze złej woli. Dzieje się to, ponieważ drugi proces z definicji otrzymuje mniej uwagi niż pierwszy.
Raport, który jest faktycznie czytany, to raport, który wpisuje się w istniejący rytm: to samo posiedzenie, ten sam format, ten sam sposób eskalacji, który już istnieje dla innych ryzyk. Jak to dopasowanie wygląda w praktyce, opisano na stronie o dopasowaniu do istniejącej struktury ryzyka, a sposób, w jaki decyzje są następnie rejestrowane, powraca na stronie o liście decyzji oversight, która wpisuje się w istniejący rytm.
Raport na jedną stronę jest użyteczny tylko wtedy, gdy leżąca za nim inwentaryzacja jest poprawna. To jest element, który jest najczęściej pomijany: członkowie zarządu otrzymują stronę z klasyfikacją ryzyka, bez sprawdzenia, czy leżąca pod nią lista zastosowań AI jest kompletna. Cień-AI — użycie, które powstało poza listą IT — wtedy po cichu wypada z obrazu, nie dlatego, że jest nieważne, lecz dlatego, że nikt o to nie zapytał. Pracownik, który używa narzędzia AI bez zatwierdzenia, nie zgłosi tego sam z siebie, gdy grozi rozliczenie. Zgłosi to tylko wtedy, gdy pytania są zadawane bez konsekwencji.
Strona z jednej strony jest więc szczytem procesu, który zaczyna się od inwentaryzacji i eskaluje poprzez ścieżki, które już istnieją. Jak ta eskalacja działa bez tworzenia nowej hierarchii, opisano na stronie o ścieżkach eskalacji, które są faktycznie używane. A co musi być strukturalnie monitorowane, aby móc wypełniać stronę każdy raz na nowo bez konieczności rekonstrukcji, opisano na stronie o monitorowaniu, które faktycznie coś przynosi dla raportowania.
Responsible AI Scan dostarcza inwentaryzację, klasyfikację i strukturę governance, która wpisuje się w to, co już istnieje — łącznie z formatem raportu, który zarząd faktycznie czyta. Sam skan jest w trakcie budowy; kto chce już teraz z tego skorzystać, może zapisać się na listę oczekujących.
Raport, który wskazuje, jaka część pracy podpada pod ryzyko AI, sam z siebie wywołuje inne pytanie: jaka część pracy sama może zostać przejęta przez AI. To jest inne rachunek, sporządzany na poziomie zadania, a nie systemu, i ten rachunek wykonuje werkscan van FTE TO AI.
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.