Przegląd zatwierdzonego oprogramowania mówi, co zostało zakupione, nie co jest używane. Między tymi dwoma rzeczami istnieje różnica, która staje się większa, w miarę jak narzędzia AI stają się coraz łatwiej dostępne: rozszerzenie do przeglądarki, darmowe konto, chatbot, który ktoś z własnej inicjatywy zastosował, by szybciej wykonać zadanie. To, co dane zakupowe i licencyjne zdradzają, jest punktem wyjścia, ale nie punktem końcowym. Reszta odpowiedzi leży u osób, które wykonują pracę.
Jeśli zapyta Pan/Pani "czy używa Pan/Pani narzędzi AI, które nie zostały zatwierdzone", zazwyczaj nie otrzyma Pan/Pani pełnej odpowiedzi. Nie dlatego, że ludzie chcą coś ukryć, ale dlatego, że pytanie sugeruje ryzyko. Kto przyznaje, że korzysta z narzędzia, które nie znajduje się na liście, oczekuje konsekwencji: ostrzeżenia, rozmowy z przełożonym, wpisu w dokumentacji. Ta perspektywa jest wystarczająca, aby kogoś zmusić do milczenia, nawet jeśli użycie jest niewinne, a nawet użyteczne.
Skutkiem jest zniekształcony obraz. Nie dlatego, że nic się nie dzieje, ale dlatego, że to, co się dzieje, nie jest zgłaszane. Inwentaryzacja, która opiera się jedynie na zgłoszeniach, rejestruje przede wszystkim to, co już było znane.
Samo pytanie niczego nie zmienia, jeśli kontekst pozostaje niezmienny. Co działa, to kilka elementów razem: pytanie jest oddzielone od indywidualnego momentu oceny, odpowiedzi nie są przypisywane do nazwiska w raporcie idącym wyżej, a cel jest wyjaśniony z wyprzedzeniem — chodzi o przegląd organizacji, nie o ocenę osoby.
Nie znaczy to, że nie odbywa się żadna ankieta czy rozmowa. Znaczy to, że pytanie jest postawione w ramach, w których "tak, używam tego" nie jest powodem do korekty. Tylko wtedy odpowiedź przesuwa się od tego, co dana osoba myśli, że chce Pan/Pani usłyszeć, do tego, co naprawdę się dzieje.
Wynik dobrze przeprowadzonej rozmowy to nie lista nazw narzędzi. To zbiór danych, który dla każdej aplikacji można powiązać z zadaniem lub procesem: która aplikacja, dla jakiej części pracy, z jakimi danymi, i kto jeszcze ma z nią do czynienia. To ta sama struktura, co co należy zapisać dla każdej aplikacji, gdy aplikacja wychodzi na jaw poprzez zakupy lub IT — jedynie źródłem jest tutaj użytkownik, a nie umowa.
Konkretnie oznacza to: nazwę aplikacji, krótki opis, do czego jest używana, szacunek częstotliwości oraz wskazanie typu danych, które są do niej wprowadzane. Bez specyfikacji technicznych, bez oceny dostawcy na tym etapie — to nastąpi później, przy klasyfikacji. Na tym etapie chodzi o zdobycie wglądu, nie o osądzanie.
Te rozmowy są jednym z kanałów obok sygnałów technicznych, które konsultuje Pan/Pani osobno. To, co zbiera Pan/Pani od użytkowników, umieszcza Pan/Pani obok które sygnały IT są użyteczne jako osobny wątek, i tylko przy ich połączeniu powstaje pełniejszy obraz, niż każde z tych źródeł oddzielnie daje. Aplikacja, która pojawia się w logach sieciowych, ale nikt jej nie wyjaśnia, pozostaje znakiem zapytania. Aplikacja, która jest wymieniona w rozmowie, ale nie pozostawia żadnego cyfrowego śladu, jest równie realna — a być może właśnie dlatego łatwiej ją przeoczyć.
Kolejność i częstotliwość takich zapytań zależy od organizacji: liczba działów, poziom warstwowości w liniach raportowania, wcześniejsze doświadczenie z tego typu inwentaryzacją. W organizacji z wieloma lokalizacjami lub warstwową strukturą jak zapytać o to pracowników bez rozliczania działa nieco inaczej niż w przypadku jednej lokalizacji z płaską strukturą, po prostu dlatego, że liczba warstw pośrednich, w których "brak rozliczania" musi się utrzymać, jest większa.
Szczera odpowiedź pracowników jest surowcem dla dalszej części inwentaryzacji. Bez tego surowca klasyfikuje Pan/Pani listę, którą już Pan/Pani znał, a to nie jest inwentaryzacja, lecz potwierdzenie. Z tym surowcem może Pan/Pani przejść do jak zbudować inwentaryzację AI na skali wykraczającej poza jeden dział lub jedną lokalizację, z danymi napływającymi z wielu kierunków jednocześnie.
Ton pytania współokreśla więc jakość odpowiedzi. To nie jest kwestia sprytniejszego sformułowania, ale struktury, w której udzielenie odpowiedzi nie niesie ze sobą ryzyka.
Gdy staje się jasne, jakie aplikacje są faktycznie używane i do jakich zadań, pytanie przesuwa się od "czego używamy" do "co to znaczy dla samej pracy". To inne pytanie, wymagające innego narzędzia. Skan pracy FTE TO AI wylicza dla każdego zadania, jaką część pracy można przekazać AI, na podstawie zadań, które już Pan/Pani zmapował poprzez tę inwentaryzację. Podczas gdy Responsible AI Scan przedstawia wykorzystanie i ryzyka, skan pracy patrzy na treść pracy: które zadania nadają się do przekazania i w jakim stopniu. Te dwa pytania leżą blisko siebie, ale nie są wymienne.
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.