Lider programu AI zazwyczaj otrzymuje jeden mandat: zapewnić, że AI zostanie wdrożone, że zespoły pracują szybciej, że program przynosi wyniki. Rzadko dochodzi drugi mandat: zapewnić, że wszystko, co powstaje w międzyczasie, jest odpowiedzialne. Mimo to jest oceniany na podstawie obu, gdy coś pójdzie nie tak. To jest istota jego ryzyka: jest odpowiedzialny za program, którego granic nie znaje.
To, co zyskuje z adopcji — szybsze procesy, zadowolone zespoły, widoczną historię innowacji — stoi w kontraście do tego, co traci, gdy coś pójdzie nie tak: incydent z narzędziem, które nie znajdowało się na jego liście, audyt, który zadaje pytania, na które nie ma odpowiedzi, zarząd, który pyta, czemu program nie zauważył tego, co już działało. Ta asymetria czyni jego pozycję wrażliwą, nawet gdy sam program przebiega dobrze.
Jego pytanie nie brzmi "jakie narzędzia AI zatwierdziliśmy". Tę listę już posiada i jest ona często krótsza niż rzeczywistość. Jego pytanie brzmi: co używają zespoły, które nie znajdują się na mojej liście, i jak zdobyć wgląd w to, bez tego, że ludzie to ukrywają. Lider programu, który chce stymulować adopcję, nie może pozwolić sobie na to, aby użytkownicy skrywali swoje narzędzia z obawy przed korektą. Kto pyta, co jest używane, a następnie robi z tego problem, przy następnym pytaniu nie otrzyma już odpowiedzi. Governance i adopcja działają tu wzajemnie przeciwko sobie, jeśli podejść do tego w niewłaściwy sposób.
Odpowiedź, którą nie akceptuje, to jednorazowa blokada: "Użycie AI bez zatwierdzenia nie jest dozwolone." Ta odpowiedź na moment satysfakcjonuje audytora, ale przenosi użycie na miejsca, których nikt nie widzi. To jest odwrotność tego, co lider programu chce osiągnąć: chce, aby użycie AI było widoczne i wspierane, a nie żeby przenosiło się do podziemia. Zakaz bez mechanizmu do zgłaszania i uczenia się jest dla niego stratą, nawet jeśli na papierze wydaje się zgodny z przepisami.
Nie akceptuje również odpowiedzi, która traktuje wszystko jednakowo. Narzędzie, które podsumowuje tekst do użytku wewnętrznego, nie stanowi tego samego ryzyka co narzędzie, które automatycznie podejmuje decyzje dotyczące klientów lub pracowników. Bez rozróżnienia według roli i poziomu ryzyka program nie może ustalać priorytetów, a lider programu, który nie może ustalać priorytetów, nie może wykonywać swojego mandatu.
Co faktycznie działa, to inwentaryzacja, która zaczyna się od tego, co istnieje, a nie od tego, co zostało zatwierdzone. To oznacza zadawanie zespołom pytań o to, co faktycznie używają, i robienie tego w sposób, który nie wiąże się z rozliczeniem. Tylko wtedy staje się widoczne shadow AI — systemy wprowadzone bez formalnego procesu, często ponieważ ułatwiały pracę i nikt nie widział powodu, aby czekać na zatwierdzenie.
Potem następuje klasyfikacja: które zastosowanie dotyka klientów, które dotyka tylko wewnętrznego procesu, które podejmuje decyzje bez człowieka pomiędzy. Ten podział determinuje, gdzie nadzór musi być ścisły, a gdzie może pozostać lekki. Bez tego podziału program traktuje wszystko jednakowo ściśle lub jednakowo lekko, i obie sytuacje są problemem: pierwsza spowalnia adopcję, druga pozwala na niekontrolowane ryzyka.
Struktura governance, która wynika z tego, musi być zgodna z tym, co już istnieje w organizacji — istniejące komitety ryzyka, istniejące linie raportowania — nie nowy obwód obok. Właśnie tu lider programu odróżnia się od innych ról w organizacji: członek zarządu chce wiedzieć co członek zarządu powinien wiedzieć o ryzyku AI na poziomie ostatecznej odpowiedzialności, CIO podchodzi do tego z perspektywy systemów i dostępu, jak opisano w co CIO powinien wiedzieć o ryzyku AI, a General Counsel patrzy na odpowiedzialność prawną i obowiązek dokumentacji poprzez co General Counsel powinien wiedzieć o ryzyku AI. Lider programu musi być w stanie obsłużyć te trzy perspektywy, nie tracąc przy tym swojego własnego zadania — adopcji.
Jakie konkretne obowiązki obowiązują dla jakiej kategorii ryzyka i w jakich terminach, nie jest tematem tej strony. Ten tekst zmienia się, jest zaostrzany i otrzymuje wyjaśnienia w innych miejscach. Tutaj chodzi o mechanizm: jak program zdobywa wgląd w to, co się dzieje, jak to przekłada na poziomy ryzyka i jak to wykazuje wobec zarządu i nadzoru, niezależnie od tego, co dokładny tekst przepisów przewiduje w danym momencie.
Gdy stanie się jasne, co działa i kto za to odpowiada, powstaje kolejne pytanie: co przynosi to, jeśli ta praca zostanie dobrze zorganizowana. To jest pytanie, na które należy odpowiedzieć na poziomie zadania, nie na poziomie organizacji. Skan pracy FTE TO AI wylicza na tym poziomie, jaka część pracy może zostać przejęta przez AI, tak aby lider programu wiedział nie tylko, co się dzieje, ale też, gdzie dodanie zdolności produkcyjnej faktycznie robi różnicę.
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.