Wiele organizacji zakłada, że ich rola jest ustalona: są użytkownikiem systemu zbudowanego przez dostawcę, a związane z tym obowiązki są jasne i trwałe. To założenie często się sprawdza, ale nie zawsze. Rola, jaką organizacja ma względem systemu AI, nie jest stałą etykietą. Jest wynikiem tego, co faktycznie dzieje się z systemem, a ten wynik może się zmienić bez podpisania nowej umowy czy dokonania nowego zakupu.
Klasyfikacja roli zależy od kilku faktycznych elementów, a nie od tego, jak dostawca nazywa system, czy jak wewnętrzny dział pozycjonuje go wewnętrznie. Istotne jest między innymi, kto wprowadził system na rynek, kto faktycznie korzysta z systemu w ramach własnego procesu oraz kto dokonał zmian w systemie po jego dostarczeniu. Ma również znaczenie, pod jaką nazwą system jest udostępniany zewnętrznie oraz czy organizacja przekazuje system innym bez samodzielnego korzystania z niego. Te elementy razem determinują, czy organizacja występuje jako dostawca, jako użytkownik, czy jako strona, która znajduje się gdzieś pomiędzy.
Powodem, dla którego ma to znaczenie dla governance, jest to, że rola determinuje, jakie obowiązki przypisane są do jakiej strony. Organizacja, która jest wyłącznie użytkownikiem, ma inne obowiązki niż organizacja, która faktycznie działa jako dostawca. To, czego dokładnie oczekuje się od każdej roli, opisane jest w innym miejscu; tutaj chodzi o mechanizm, który determinuje, jaka rola ma zastosowanie, oraz o rozpoznanie momentu, w którym ten mechanizm daje inny wynik niż wcześniej.
Rola nie jest przypisana do systemu na cały okres jego użytkowania. Jest powiązana z tym, co faktycznie dzieje się w danym momencie. To oznacza, że ta sama organizacja przy tym samym systemie może w dwóch różnych momentach znajdować się w innej roli. Kilka sytuacji, w których to się dzieje: zespół, który dostrajanie (fine-tuning) zakupionego modelu przeprowadza na własnych danych, dział, który zmienia oznakowanie systemu i udostępnia go pod własną nazwą innym działom, albo organizacja, która system pierwotnie przeznaczony do użytku wewnętrznego przekazuje klientowi lub partnerowi. W każdym z tych przypadków faktyczna rola się zmienia, nawet jeśli na zewnątrz zmienia się niewiele.
To, co zmienia się w praktyce, nie jest abstrakcyjne. Determinuje to, kto jest odpowiedzialny za dokumentację, kto musi wykazać, że system robi to, co deklaruje, oraz kto musi zareagować, jeśli coś pójdzie nie tak. Więcej o tym, co konkretnie się zmienia, gdy model jest dostosowywany, opisano na stronie o zmianach w modelu. Ta zmiana jest jednym z najwyraźniejszych przykładów tego, jak rola się przesuwa bez świadomej decyzji, która by ją poprzedzała.
Powodem, dla którego ten temat jest istotny nie tylko prawnie, ale też organizacyjnie, jest to, że zmiana roli często przebiega niezauważona. Zespół, który dostosowuje model, myśli o technicznym usprawnieniu, nie o zmianie odpowiedzialności. Dział, który przekazuje narzędzie innemu działowi, myśli o wygodzie, nie o nowej roli jako dostawca. Governance, które patrzy tylko na to, co zostało zakupione, systematycznie przeoczy te przesunięcia.
Jest to związane z pytaniem, które zastosowania dokładnie podlegają danej regulacji, a które nie; ta granica jest omówiona na stronie o zakresie zastosowań. System, który znajdował się poza zakresem w momencie zakupu, może wejść w zakres, gdy zmieni się rola organizacji. To sprawia, że jednorazowa ocena przy zakupie nie jest wystarczająca; ocena musi być dostosowywana na bieżąco do tego, co faktycznie dzieje się z systemem.
Również poziom ryzyka danego zastosowania może zmieniać się wraz ze zmianą roli. To, co dokładnie oznacza wysoki poziom ryzyka dla obowiązków organizacji i od czego to zależy, wyjaśniono na stronie o skutkach wysokiego poziomu ryzyka. Organizacja, która w wyniku zmiany roli nagle zaczyna być uznawana za dostawcę systemu o wysokim poziomie ryzyka, ma inne obowiązki niż wtedy, gdy była wyłącznie użytkownikiem tego samego systemu.
Aby rozpoznać zmiany roli, zanim staną się problemem, organizacja musi wiedzieć, jakie systemy istnieją, kto je dostosowuje i kto przekazuje je komu. To wymaga inwentaryzacji sięgającej dalej niż lista zatwierdzona przez IT, oraz stałego miejsca, w którym rejestrowane są decyzje dotyczące dostosowań, przekazywania i zmiany oznakowania. Takie stałe miejsce oraz związane z nim pytania opisano na stronie o rejestrze decyzji nadzorczych.
Responsible AI Scan został zbudowany, aby uwidocznić te przesunięcia: jakie systemy faktycznie działają, kto z nich korzysta, kto je dostosował oraz jaka rola z tego w danym momencie wynika. Narzędzie wspierające to jest w trakcie budowy; osoby zainteresowane skorzystaniem z niego mogą zapisać się na listę oczekujących.
Zmiana roli dotyka nie tylko governance. Gdy system przechodzi z pojedynczego narzędzia pomocniczego do czegoś, co strukturalnie przejmuje część zadania, zmienia się również pytanie, ile pracy ten system faktycznie wykonuje i ile jeszcze pozostaje po stronie ludzi. Werkscan FTE TO AI wylicza dla każdego zadania, jaką część pracy można przekazać AI, ujawniając w ten sposób, gdzie zmiana roli w governance zbiega się z faktycznym przesunięciem w podziale pracy.
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.