Lista decyzji nadzorczych to nie nowy formularz i nie nowe spotkanie. To stałe miejsce, w którym zapisuje się, które zastosowanie AI zostało ocenione, przez kogo, na podstawie jakiej oceny ryzyka i z jaką decyzją. Zatwierdzone, odrzucone, warunkowo, lub tymczasowo dopuszczone w oczekiwaniu na dalsze badanie. Bez takiej listy decyzja istnieje wyłącznie w pamięci osób, które były przy niej obecne, i zanika, gdy ktoś zmienia funkcję albo rozmowa nie została odnotowana w protokole.
Lista zawiera dla każdego zastosowania krótki opis zadania, klasyfikację według roli i poziomu ryzyka, nazwę właściciela procesu, datę oceny, podjętą decyzję i jej uzasadnienie. Żadnej specyfikacji technicznej, żadnej dokumentacji dostawcy: to należy do dokumentacji samego zastosowania, nie do listy decyzji. Lista to przegląd na poziomie wyższym — kto o czym zdecydował i kiedy tę decyzję ostatnio potwierdzono. Zastosowanie, które rok temu zatwierdzono dla zadania o ograniczonym ryzyku, może obecnie być używane do czegoś innego. Bez okresowego potwierdzania stara decyzja pozostaje w mocy dla sytuacji, która już nie istnieje.
Powodem, dla którego osobne rejestry AI często pozostają puste, nie jest niechęć, lecz kolejność. Każda organizacja ma już miejsce, gdzie omawia się i rejestruje ryzyka: komitet ryzyka, komisję audytową, posiedzenie zarządu ze stałym punktem dotyczącym ryzyka operacyjnego. Kto tworzy do tego osobny dziennik AI, prosi ludzi o prowadzenie drugiej administracji dla czegoś, co merytorycznie należy do pierwszej. Ten drugi proces systematycznie przegrywa z codziennym pędem pracy. Lista decyzji nadzorczych działa tylko, gdy jest wbudowana w to, co już istnieje — jako stały element istniejącego posiedzenia, ze stałym miejscem w porządku obrad, a nie jako nowy obowiązek dodany obok.
Oznacza to również, że lista używa tej samej skali i tego samego języka, co pozostała część struktury ryzyka. Zastosowanie o wysokim poziomie ryzyka otrzymuje taki sam rodzaj uwagi jak inna sprawa o wysokim poziomie ryzyka: stała częstotliwość raportowania, stały właściciel, stała linia eskalacji. Jak to połączenie wygląda w praktyce, zależy od istniejącego zarządzania w organizacji i jest opisane na stronie o dopasowaniu do istniejącej struktury ryzyka.
Lista decyzji jest bezużyteczna bez ścieżki określającej, co się dzieje, gdy ktoś się z nią nie zgadza, albo gdy zastosowanie się zmienia bez zgłoszenia. Ta ścieżka nie powinna znajdować się w samej liście, ale musi z nią współdziałać: kto może odwołać się od odrzucenia, kto musi przedłużyć tymczasową zgodę i do kogo trafia sprawa, gdy właściciel procesu i funkcja ryzyka się nie zgadzają. Jak te linie przebiegają, tak by każda sprawa nie trafiała na samą górę organizacji, opisano na stronie o działających ścieżkach eskalacji.
Lista decyzji jest pamięcią; zarząd potrzebuje ponadto podsumowania, którego nie trzeba co kwartał na nowo składać z osobnych protokołów. Co powinno znajdować się w takim podsumowaniu — a czego właśnie nie, bo już znajduje się na liście decyzji — opisano na stronie o raporcie dla zarządu na jedną stronę. Bez tego kroku lista decyzji pozostaje dokumentem, który czytają jedynie właściciele procesów, podczas gdy zarząd pozostaje prawnie odpowiedzialny za to, co się decyduje.
Zarejestrowanie decyzji nie jest tym samym, co wiedza, czy decyzja jest przestrzegana. Zastosowanie, które zostało odrzucone, może nadal być używane, jeśli nikt nie sprawdza, czy odrzucenie zostało wdrożone. To powód, dla którego lista decyzji bez kontynuacji daje niewiele: dokumentuje intencje, nie zachowanie. Co jest potrzebne, aby zobaczyć, czy decyzja się utrzymuje, i jakie sygnały do tego należą, opisano na stronie o monitorowaniu, które coś daje.
Lista decyzji może zawierać tylko to, co zostało zgłoszone. Kto zależy od zgłoszeń przekazywanych przez dział IT, widzi tylko część tego, co faktycznie jest używane: większa część zastosowań AI w organizacji powstaje poza formalnymi procesami zakupowymi, w zespołach, które testują narzędzie, bo działa. Czy te zastosowania kiedykolwiek znajdą się na liście decyzji, zależy od tego, czy pracownicy odważą się powiedzieć, co używają — a to zdarza się tylko wtedy, gdy pytania o to nie odczuwane są jako przedsionek sankcji.
Pierwsze pytanie, które w tym pomaga, to nie 'jakie AI zostało zatwierdzone', lecz 'jaka część tej pracy jest już właściwie wykonywana przez AI, albo mogłaby być'. To inny punkt wejścia niż lista decyzji i pełniejszy punkt wyjścia: skan pracy FTE TO AI oblicza dla każdego zadania, jaką część pracy można przejąć przez AI, tworząc tym samym podstawę, która nie zależy od tego, co przypadkowo zostało zgłoszone. Na podstawie tego wyniku widać, które zastosowania faktycznie już działają, zanim lista decyzji kiedykolwiek o nich się dowie.
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.