Jakiś czas temu obiecałem, że pogłębimy temat zarządzania ryzykiem AI. A skoro tak, to czynię zadość tej deklaracji. Zarządzanie ryzykiem AI jest częścią procesu zarządzania systemami AI (AI Governance) i nie należy do najłatwiejszych, bo o ile w przypadku wielu „typowych” ryzyk możemy określić jedną kategorię i przypisać ją do konkretnej jednostki lub obszaru, o tyle w przypadku AI mamy istny „ocean możliwości”. I nie jest to, niestety, dobra informacja. Dobra jest z kolei taka, że jeżeli dobrze zrozumiemy specyfikę tych ryzyk, to zarządzanie będzie nieco łatwiejsze, choć nadal wymagające. To rezultat tego, że AI nie jest stała jak tradycyjne oprogramowanie – po wprowadzeniu stale ewoluuje (chyba że pójdziemy w statyczność), wymaga nadzoru i kontroli, a dane płyną w taki czy inny sposób do naszego modelu. Sprawa komplikuje się jeszcze bardziej, gdy włączamy do gry generatywną AI, ale o tym za chwilę.

Systemy zarządzania ryzykiem AI

Sam system zarządzania ryzykiem (także AI) jest także niekiedy wymogiem prawnym i dobrym przykładem będzie tutaj sektor finansowy, w którym takie systemy muszą być wdrażane i utrzymywane, aby chronić środki oraz dane klientów. Nie wyodrębnia się wśród nich ryzyk związanych z AI (ale w regulacyjnym aspekcie mowa np. o modelach), jednak rozumie się to samo przez się. AI jest jakąś formą ryzyka, na które również instytucje finansowe są narażone. Powiem więcej: art. 105a ust. 1a ustawy – Prawo bankowe nawet (prawie) wprost referuje do AI jako zautomatyzowanego przetwarzania danych na potrzeby oceny ryzyka kredytowego i zdolności kredytowej (temat „wałkowany” jest przeze mnie od kilku lat w kontekście wyjaśnialności).

Również AI Act w art. 9 wymusza na dostawcach systemów wysokiego ryzyka, aby ci ustanowili, wdrożyli, dokumentowali i obsługiwali system zarządzania ryzykiem w odniesieniu do tych systemów, a jednym z elementów tego procesu ma być identyfikacja i analiza znanego i dającego się racjonalnie przewidzieć ryzyka, jakie dany system AI wysokiego ryzyka może stwarzać dla zdrowia, bezpieczeństwa lub praw podstawowych podczas jego stosowania zgodnie z przeznaczeniem.

My na system zarządzania ryzykiem spojrzymy nieco szerzej, przynajmniej w kontekście potencjalnej szkody, ale mechanizm identyfikacji zasadniczo pozostanie ten sam. Przy czym nie będę się tutaj zajmował kwestiami szacowania samego ryzyka. Ten temat zostawiam na inną okoliczność. No nic, nie trzymam was dłużej w niepewności.

Źródło informacji o ryzykach AI

Ze źródłami informacji jest jak „sami wiecie z czym” – każdy ma swoje. Możemy jednak szukać inspiracji i konkretów z dostępnych standardów, które są regularnie aktualizowane. Ich autorzy starają się nadążyć za rozwojem technologii i w zasadzie całkiem nieźle się im to udaje, choć z samymi środkami zarządzania ryzykami jest trochę trudniej.

To, co powinno stanowić źródło inspiracji do stworzenia własnej matrycy, to przede wszystkim:

- AI Act, gdzie m.in. w art. 10 (zarządzanie danymi), art. 14 (nadzór człowieka) czy art. 15 (dokładność i odporność) znajdziemy (ukryte) przykłady ryzyk, które mogą nam zostać wygenerowane przez systemy AI; znaczenie mają także inne akty, jak chociażby RODO czy DORA (zarządzanie ryzykiem ICT dla sektora finansowego) i NIS2 (cyberbezpieczeństwo wybranych sektorów);

- standardy ISO, w tym ISO 42001:2023 (system zarządzania AI), ISO 27005 (zarządzanie ryzykiem bezpieczeństwa informacji), ISO 27563:2023 (dobre praktyki w zakresie ryzyk bezpieczeństwa i prywatności), ISO 38507:2022 (governance AI);

- wytyczne NIST w zakresie zarządzania ryzykiem AI (także generatywnej), które nie tylko pokazują nam, jak podejść do samego procesu (co ma istotne znaczenie, jeżeli nie robiliśmy tego wcześniej), ale dają nam też przykłady ryzyk, na które jesteśmy narażeni;

- OWASP TOP 10 LLM, czyli zestawienie ryzyk i podatności w kontekście generatywnej sztucznej inteligencji;

- CRISP-DM, czyli standard dla danych, które są paliwem dla systemów AI.

Oczywiście to nie jest gotowa matryca, którą możemy (i powinniśmy) przenieść 1:1 do naszej organizacji. Samodzielnie musimy dokonać identyfikacji tych ryzyk, które realnie w kontekście naszej organizacji występują i którymi możemy zarządzać. Jasne, możemy przygotować plik w Excelu, do którego wrzucimy kilkaset kategorii, ale będzie to tylko papier, którego nie zoperacjonalizujemy, a z którego jednak będziemy musieli się wyspowiadać w ramach audytów czy kontroli nadzorczych. Należy więc do tego podejść rozsądnie i z uwzględnieniem skali działalności naszej organizacji w tym obszarze. Bez zrozumienia (w sensie merytorycznym) tych ryzyk może być nam trudno.

Proces mapowania

Na czym właściwie polega proces mapowania? Zacznijmy w ogóle od tego, że to nie jest jedno, ale kilka działań, które należy podjąć w organizacji. Aby w przyszłości zarządzać ryzykiem AI, trzeba mieć pojęcie, co w danej organizacji się znajduje i jak to wpisuje się w jej działalność. Enigmatycznie? Chodzi o to, aby zrobić swoistą inwentaryzację zasobów.

Inwentaryzacja zasobów

Taka inwentaryzacja pozwoli nam na zorientowanie się, jak wygląda nasza architektura rozwiązań i jak są one ze sobą powiązane, ale w kontekście naszych działań w obszarze ryzyka pozwoli na „wyciągnięcie” ewentualnych podatności i realnych ryzyk, które możemy spotkać w ramach procesów projektowania, rozwijania, wdrażania i stosowania systemów sztucznej inteligencji, jak również samych modeli. Lista taka powinna być możliwie szczegółowa i obejmować także współzależności, które mogą wystąpić na skutek niewłaściwego działania jakiejś „części większej całości”.

Może pojawić się przy tym pytanie: kto ma takie informacje? Nie ma jednej odpowiedzi, ale naturalnym kierunkiem będzie jednostka odpowiedzialna za obszar IT (ma ona zazwyczaj zmapowane wszystkie systemy, aplikacje oraz infrastrukturę, które są wykorzystywane w organizacji) oraz obszar danych (np. data science), który może z kolei dysponować informacjami na temat tworzonych i wykorzystywanych modeli AI. Może też być tak, że jednostki biznesowe dysponują taką wiedzą, ale mogą one raczej wskazać nam, co robimy jako organizacja, natomiast nie będą miały pełnej wiedzy technicznej, jak coś funkcjonuje.

Takie repozytorium może przyjmować różne formy, ale najprostszym rozwiązaniem jest po prostu stworzenie tabeli w Excelu, w której będą się znajdowały kolumny odnoszące się do interesujących (lub wymaganych prawem czy regulacjami) informacji.

Identyfikacja ryzyk związanych z systemami AI

Z ww. standardu NIST AI RMF wynika, że jedną z czynności, które należy podjąć w ramach etapu „mapowanie”, jest zapewnienie, że „[r]yzyko i korzyści są mapowane dla wszystkich komponentów systemu sztucznej inteligencji, w tym oprogramowania i danych stron trzecich”.

To jest ten etap, na którym powinniśmy mieć dobrze „ogarnięte” ryzyka związane z systemami AI, bo jak inaczej można realnie ocenić, gdzie mogą pojawić się one w kontekście naszej organizacji. Oznacza to, że zanim zaczniemy mapowanie, czyli nakładanie ryzyk na poszczególne komponenty, aplikacje czy systemy, musimy sporządzić listę konkretnych ryzyk, które mogą być charakterystyczne np. dla danego modelu biznesowego czy skali cyfryzacji procesów. Innymi słowy: identyfikacja ryzyk oznacza proces „ogólnego” określenia, jakie ryzyka mogą wystąpić w kontekście naszej działalności, zaś mapowanie ryzyk to przypisanie ich do „konkretów”.

Również i w tym przypadku nie ma jednego wzorca, jak to zrobić, i trzeba mieć świadomość, że w tym miejscu mogą pojawić się pierwsze „konflikty” korporacyjne związane z „nachodzeniem” na siebie kompetencji. Zakładając, że funkcjonujemy w organizacji, w której stosujemy tradycyjny podział na trzy linie obrony (właściciele ryzyk, jednostki zarządzania ryzykiem i zgodności, audyt), mogą pojawić się „zgrzyty” na linii pierwszej i drugiej, gdzie będziemy mieli zupełnie odmienny pogląd na to, jakie ryzyka rzeczywiście występują w odniesieniu do konkretnie zmapowanych zasobów. Różnice zdań mogą pojawić się także w kontekście samego przypisania odpowiedzialności (właścicielstwa ryzyk), co może spowodować dalsze trudności.

Sprawa się komplikuje, gdy bierzemy pod uwagę to, że rozmawiamy o systemach sztucznej inteligencji. Dlaczego? Do tej pory nie pisałem za wiele o samej charakterystyce ryzyk dla AI, ale czas nadrobić zaległości (choć w skrócie, żebyście nie znudzili się zbyt szybko)

Specyfika AI. Ryzyka są „porąbane”

Dosłownie. Ryzyka związane z systemami AI można bowiem porąbać na mniejsze kawałeczki, które da się przypisać do kategorii ryzyk już istniejących w organizacji. Przykładowo, jeżeli spojrzymy na system generatywnej AI, to znajdziemy tam (oprócz ryzyk charakterystycznych dla „tradycyjnego” oprogramowania czy w ogóle IT):

- sprawiedliwość (w odniesieniu do danych, ale i wyników), niechciane uprzedzenia i dyskryminację;

- podatność na ataki charakterystyczne dla LLM (jak prompt attack);

- brak wystarczających ram monitorowania i nadzoru (ML/AIOps);

- niewystarczające kompetencje;

- brak wyjaśnialności stosowanych modeli;

- ryzyko jakości danych czy źródła danych;

- ryzyko łańcucha wartości systemu AI;

- brak zdolności do wyznaczania i monitorowania metryk;

- ryzyko modeli typu „pre-trained”;

- ryzyko „niewłaściwych” danych wyjściowych.

W rzeczywistości lista jest znacznie dłuższa i samo zidentyfikowanie i wybranie kategorii odpowiednich dla naszej organizacji może być problematyczne.

Właściciel ryzyka a właściciel zasobu

Potem pojawi się kolejne wyzwanie, czyli przypisanie właścicielstwa ryzyka. Intuicja podpowiada, że przecież ryzyko jest przypisane do zasobu, więc odpowiadać powinien właściciel zasobu. I w praktyce często tak będzie, ale co w sytuacji, w której właściciel nie jest w stanie samodzielnie sprawować kontroli nad tym ryzykiem, bo wykracza ono daleko poza jego przypisane kompetencje?

Możliwości są co najmniej dwie: „dokształcenie” lub zapewnienie procesu współpracy i koordynacji. Dokształcenie nie zawsze jest możliwe, bo trudno oczekiwać od eksperta od np. IT, aby znał się też dobrze na obszarze data science (co nie jest rzecz jasna aż taką rzadkością, ale jednak są to obszary nieco inne, wymagające innego zestawu kompetencji). Pozostaje więc stworzenie takiego mechanizmu współpracy, który zapewni przepływ informacji, ich aktualność i zdolność do reagowania, w sytuacji kiedy dojdzie np. do zmaterializowania ryzyka.

Pytań, które trzeba sobie zadać, jest więcej, w tym:

- czy budować oddzielny system lub co najmniej kategorię ryzyk dla AI, czy też postawić na wpisanie ich do istniejących i dobrze rozpoznanych kategorii;

- jak rozsądnie poukładać role i odpowiedzialności za poszczególne obszary ryzyk AI;

- w jaki sposób ułożyć procesy oraz budować świadomość, aby zapewnić, że ryzyka specyficzne dla AI są odpowiednio wcześnie identyfikowane w ramach realizacji projektów/inicjatyw AI;

- kto powinien być liderem zmiany i utrzymania takiego systemu;

- jak przekonać sponsorów, w tym zarząd, do tego, że to jest rzeczywiście ważne.

Tyle na dzisiaj. Jeżeli mierzycie się z tym problemem, to podzielcie się doświadczeniami!

Autor jest partnerem odpowiedzialnym za AI & CyberSec w ZP Zackiewicz & Partners, CEO w GovernedAI