Zespół chciał coś wypróbować. Chatbot do obsługi zapytań klientów, skrypt podsumowujący raporty, połączenie z modelem językowym do sortowania e-maili. Nie było potrzebne wielkie postanowienie: ktoś miał konto, klucz API lub darmowy okres próbny, i w ciągu jednego popołudnia coś zaczęło działać. Pilotaż działał, albo działał wystarczająco dobrze, i nikt nie miał już powodu, by go wyłączyć.
To nie jest wyjątek. To zwykły sposób, w jaki AI wchodzi do organizacji. Nie poprzez przetarg czy zatwierdzony budżet, ale poprzez stanowisko testowe, które przetrwa swój własny status testowy. Faza testowa nigdy nie została formalnie zamknięta, ponieważ nigdy nie było formalnego początku, który należałoby zamknąć.
Pilotaż, który działa, jest używany. A to, co jest używane, staje się zależnością. Zespół, który zbudował narzędzie podsumowujące raporty, może już odejść, ale podsumowanie wciąż przychodzi każdego tygodnia. Nikt nie ma zadania, by je wyłączyć, i nikt nie chce podjąć ryzyka, że coś przestanie działać, bez wiedzy, co ma to zastąpić.
Do tego dochodzi fakt, że stanowisko testowe zwykle nie ma właściciela w sensie, jakiego wymaga struktura governance. Nie przeprowadzono klasyfikacji ryzyka, nie wykonano analizy danych, nie podjęto decyzji, kto jest odpowiedzialny, jeśli coś pójdzie nie tak. Pilotaż istnieje w przestrzeni pośredniej: zbyt używany, by go ignorować, zbyt nieformalny, by go zarządzać. To dokładnie ten wzorzec, który prowadzi do sytuacji, w której pracownicy używają narzędzia, którego nikt nie zatwierdził — tylko wtedy na poziomie zespołu, a nie indywidualnym.
Odruchem po wykryciu nieautoryzowanego stanowiska testowego jest często: kto to zatwierdził i dlaczego nie wiedzieliśmy o tym. To pytanie jest zrozumiałe, ale działa odwrotnie do zamierzonego efektu. Kto już podczas pierwszej rozmowy poczuje, że nadchodzi pytanie o winę, następny raz nie powie już nic. A następne stanowisko testowe — które z pewnością się pojawi — zniknie z pola widzenia dokładnie tak samo jak to.
Inwentaryzacja zbudowana na zaufaniu daje więcej niż audyt zbudowany na kontroli. Nie dlatego, że ludzie nie mieliby niczego do ukrycia, ale dlatego, że informacja, której szukacie, znajduje się u użytkownika, a ten użytkownik mówi tylko wtedy, gdy nie jest rozliczany za to, co znajdzie.
Gdy stanowisko testowe zostanie zidentyfikowane, pierwszym pytaniem nie jest, czy może dalej istnieć, ale co właściwie robi. Jakie dane do niego wchodzą, kto korzysta z wyniku i co się dzieje, gdy wynik jest błędny. To te same pytania, które obowiązują dla każdego innego zastosowania AI, a odpowiedź decyduje, czy coś jest nieformalnym narzędziem pomocniczym, czy ryzykiem wymagającym uwagi.
Potem następuje klasyfikacja: czy zastosowanie wpisuje się w kategorię ryzyka, która już istnieje, czy wymaga nowej oceny. Następnie: co należy odnotować, aby wykazać, że organizacja wie, co działa i dlaczego. To jest właśnie tematem co należy odnotować dla każdego zastosowania — nie jako dodatkowa biurokracja, ale jako minimalna dokumentacja potrzebna do odróżnienia pilotażu od ryzyka.
Stanowisko testowe, które przejdzie ten test, może dalej istnieć, teraz z właścicielem i klasyfikacją. Stanowisko testowe, które tego testu nie przejdzie, musi zostać wygaszone — ale to jest proces kontrolowany, a nie zwolnienie osoby, która je kiedyś rozpoczęła.
Stanowisko testowe, które nigdy nie zostało wyłączone, jest jedną z form szerszego wzorca. Pomyślcie o rozszerzeniu przeglądarki z dostępem do skrzynki mailowej, które ktoś kiedyś zainstalował, aby zaoszczędzić czas, albo o danych firmowych, które trafiają do darmowego okna czatu, bo to szło szybciej niż korzystanie z oficjalnego narzędzia. Wszystkie te sytuacje mają jedną wspólną cechę: powstały z praktycznej potrzeby, a nie z decyzji politycznej, i istnieją dalej, dopóki nikt o nie nie zapyta.
Lista zatwierdzonego przez IT oprogramowania nie jest więc punktem wyjścia inwentaryzacji — jest punktem początkowym poszukiwania tego, co wykracza poza tę listę. Kto chce wiedzieć, jak wygląda takie poszukiwanie, znajdzie podejście w jak zbudować inwentaryzację AI.
Stanowisko testowe, które wychodzi na światło dzienne, zazwyczaj wywołuje pytanie idące dalej niż governance: dlaczego to właściwie działało tak dobrze, że nikt nie odważył się tego zatrzymać? To pytanie o samą pracę, nie tylko o ryzyko. Skan pracy FTE TO AI oblicza dla każdego zadania, jaka część pracy może zostać przejęta przez AI, dzięki czemu ukazuje to, co stanowisko testowe już implicite pokazywało: że część pracy może zostać zorganizowana inaczej. Podczas gdy Responsible AI Scan mapuje, co działa i pod jakim ryzykiem, skan pracy pokazuje, skąd to użycie się bierze i co to strukturalnie oznacza dla podziału zadań.
Responsible AI Scan, wraz z inwentaryzacją, klasyfikacją i zestawem governance opisanymi powyżej, jest w fazie rozwoju. Kto już teraz ma z tym do czynienia i chce być poinformowany, gdy instrument będzie dostępny, może zapisać się na listę oczekujących.
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.