Zanim poziom ryzyka, obowiązek czy środek governance nabierze znaczenia, musi być jasne, jaką rolę odgrywa pana/pani organizacja. Kto wprowadza system AI na rynek, ma inne obowiązki niż ten, kto wdraża system zbudowany przez kogoś innego. Termin używany do tego rozróżnienia jest znany: dostawca wobec użytkownika. Ale sam podział nie jest zapisany w schemacie organizacyjnym. Zależy od tego, co organizacja robi z konkretnym systemem, a to może się różnić w zależności od systemu, działu i momentu.
Kluczowe pytanie nie brzmi, kto kupił lub zainstalował system, ale kto wprowadził go na rynek albo udostępnia go pod własną nazwą. Organizacja, która kupuje i wykorzystuje oprogramowanie tak, jak zostało dostarczone, jest zazwyczaj użytkownikiem. Organizacja, która rozwija system, zleca jego rozwój pod własną nazwą, lub modyfikuje istniejący system w taki sposób, że funkcjonalnie staje się czymś innym, może w ten sposób znaleźć się w roli dostawcy. To ostatnie jest często momentem, w którym organizacje się mylą: dostrajanie modelu, budowanie własnej warstwy na zewnętrznym systemie lub trenowanie chatbota na własnych danych może przesunąć rolę bez tego, by ktokolwiek odczuł to jako świadomą decyzję. Co dokładnie liczy się jako modyfikacja zmieniająca rolę, opisano na stronie co się zmienia, gdy samodzielnie dostosowuje pan/pani model.
Większość organizacji nie jest wyłącznie dostawcą albo wyłącznie użytkownikiem. Bank, który wykorzystuje zewnętrzny model językowy do obsługi klienta, jest w tym zakresie użytkownikiem, ale jeśli ten sam bank udostępnia wewnętrznie opracowany model ryzyka innemu działowi lub klientowi, dla tego systemu powstaje rola dostawcy. To oznacza, że podział musi być dokonywany dla każdego zastosowania, nie jednorazowo dla całej organizacji. Inwentaryzacja, która dla każdego systemu określa, kto go zbudował, kto go zmodyfikował i kto go używa, jest więc jedynym sposobem, aby odpowiedzieć na to pytanie w sposób strukturalny, a nie przypadkowy.
Rola nie jest stałą cechą organizacji, lecz statusem podlegającym zmianie. Dostawca może zmienić swój system w sposób, który wpływa na profil ryzyka. Wewnętrzny programista może rozwinąć wewnętrzne narzędzie do postaci, która jest oferowana poza organizacją. System, który pojawił się jako proste narzędzie, może po aktualizacji wykonywać zadania, które umieszczają go w innej kategorii ryzyka. Kiedy konkretnie dochodzi do takiego przesunięcia i co to oznacza dla tego, kto wtedy jest odpowiedzialny, wyjaśniono na stronie kiedy zmienia się pana/pani rola. Dla organizacji, które chcą zrozumieć, co przesunięcie w kierunku wyższego poziomu ryzyka oznacza w praktyce, dalsze omówienie znajduje się na stronie co oznacza wysoki poziom ryzyka dla pana/pani organizacji.
Nie każde zastosowanie określane jako sztuczna inteligencja wchodzi w zakres, dla którego podział ról jest istotny. Niektóre systemy wykraczają poza zakres, dla którego ten podział został stworzony, i dla organizacji jest równie ważne, aby wiedzieć, co wykracza poza zakres, jak i to, co się w nim znajduje. W przeciwnym razie czas jest poświęcany na klasyfikację czegoś, co klasyfikacji nie wymagało, albo coś zostaje przeoczone, ponieważ wydawało się zbyt małe. Które zastosowania wykraczają poza te ramy i dlaczego, opisano na stronie które zastosowania wykraczają poza zakres.
Określenie roli jest pierwszym krokiem, a nie wynikiem procesu governance. Po podziale następuje pytanie, co faktycznie musi się wydarzyć dla każdej roli i każdego poziomu ryzyka, a to pytanie rozpada się na dwie kategorie: to, co wymaga natychmiastowej uwagi, i to, co można zaplanować na dłuższą perspektywę czasową. Te dwie kategorie są często mylone, w wyniku czego sprawy pilne pozostają nierozwiązane, podczas gdy czas jest poświęcany czemuś, co jeszcze nie jest naglące. Przegląd tego, co ma w tym zakresie priorytet, znajduje się na stronie co trzeba zrobić teraz, a co można zaplanować. Kto chce dalej zgłębić pytanie o podział ról, wraz z precyzyjnymi kryteriami wyznaczającymi granicę między dostawcą a użytkownikiem, znajdzie to omówienie na stronie czy pan/pani jest dostawcą czy użytkownikiem: od czego to zależy.
Ten podział ma sens tylko wtedy, gdy jest stosowany do tego, co naprawdę działa w organizacji, a nie do tego, co znajduje się na zatwierdzonej liście. Systemy wprowadzone bez zgody liczą się w równym stopniu, a rola, która im odpowiada, musi zostać ustalona równie dokładnie. To wymaga inwentaryzacji, która wykracza poza administrację IT.
Jak tylko staje się jasne, jaką rolę organizacja odgrywa dla danego systemu, uwaga naturalnie przesuwa się na inne pytanie: co te systemy właściwie robią i jaką część pracy przejmują. To pytanie leży poza skanem governance, ale bezpośrednio się z nim łączy. Skan pracy FTE TO AI wylicza dla każdego zadania, jaką część pracy można przejąć za pomocą AI, dając w ten sposób obraz wpływu systemu obok obrazu związanych z nim obowiązków.
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.