Dostawca dostarcza pakiet księgowy, system HR lub narzędzie do obsługi klienta. Istnieje umowa, umowa powierzenia przetwarzania danych, może audyt bezpieczeństwa. Następnie dostawca w ramach aktualizacji dodaje funkcję AI: automatyczną klasyfikację, sugestie tekstowe, chatbota puszczonego na Państwa dane. Notatki o wydaniu nazywają to ulepszeniem. Nikt w Państwa organizacji nie miał nic do powiedzenia w tej sprawie, ponieważ nikt nie wiedział, że to nadchodzi.
Nie jest to wyjątek od sposobu dostarczania oprogramowania. Stało się to standardem. Dostawcy konkurują funkcjonalnością AI i wbudowują ją jak najszybciej, często jako część abonamentu, który już Państwo płacą. Pytanie, czy to wchodzi w zakres istniejących ustaleń, rzadko jest zadawane przed uruchomieniem funkcji.
Dział zakupów ocenia dostawcę przy zakupie. Później uwaga przesuwa się na fakturę, dostępność systemu (uptime) i wsparcie. Aktualizacje funkcjonalne odbywają się poza tym procesem, ponieważ podpadają pod utrzymanie, nie pod nowy zakup. Kto powinien to zgłosić? Dostawca widzi to jako ulepszenie produktu. Osoba odpowiedzialna za zakupy nie widzi aktualizacji, albo widzi ją i sądzi, że to sprawa kogoś innego. Użytkownik w organizacji zauważa głównie, że przycisk robi coś sprytniejszego, i nie zastanawia się, czy stoi za tym model językowy przetwarzający dane zewnętrznie.
Wzorzec przypomina to, co dzieje się przy rozszerzeniu przeglądarki z dostępem do Państwa poczty: dostęp zostaje udzielony w momencie, gdy nikt nie myślał o AI, i pozostaje potem niezauważony i aktywny. U dostawców problem skali jest większy, ponieważ dotyczy nie jednego pracownika, lecz całej organizacji wystawionej na ryzyko przez jedną umowę.
Postanowienie umowne wymuszające obowiązek powiadomienia przy funkcjonalności AI pomaga w nowych umowach. W istniejących umowach takiego postanowienia nie ma, i nie jest oczywiste, że dostawca zaakceptuje je z mocą wsteczną. Ponadto klauzula nie rozwiązuje problemu wykrywania: jeśli nikt okresowo nie sprawdza, co dostawca faktycznie dodał, powiadomienie wciąż zależy od gotowości dostawcy do samodzielnego zgłoszenia tego.
Co natomiast działa, to stałe zdjęcie sytuacji: okresowa inwentaryzacja tego, jaką funkcjonalność AI każdy kluczowy dostawca dostarcza w danym momencie, oddzielona od tego, co zostało oceniane przy zakupie. To nie jest instrument prawny, a rzeczowy przegląd, który następnie można porównać z kategorią ryzyka procesu, w którym dostawca działa.
Ta sama dynamika, która utrzymuje shadow AI wśród pracowników, działa również tutaj, tylko na poziomie dostawców. Ktoś, kto zadaje pytanie „czy używacie do tego AI”, chce uczciwej odpowiedzi, nie reakcji obronnej menedżera obsługującego konto. Oznacza to, że pytanie nie powinno być zadawane jako wstęp do rozwiązania umowy, lecz jako część stałego procesu, w którym odpowiedź nie ma konsekwencji innej niż klasyfikacja. Zobacz, jak to działa u pracowników używających narzędzia, którego nikt nie zatwierdził: przydatna informacja wychodzi na jaw tylko wtedy, gdy zadawanie pytań jest oddzielone od karania.
Lista dostawców jest punktem wyjścia, nie punktem końcowym. Dla każdego dostawcy, który ma dostęp do danych produkcyjnych, danych klientów lub danych personalnych, istotne jest, czy zawiera obecnie funkcjonalność AI, co ta funkcjonalność robi z danymi i czy to zastosowanie wchodzi w tę samą kategorię ryzyka, dla której dostawca był pierwotnie zatwierdzony. Dostawca, który pięć lat temu został oceniony jako niskiego ryzyka, ponieważ jedynie wystawiał faktury, może teraz obsługiwać moduł, który automatycznie klasyfikuje faktury na podstawie modelu językowego wytrenowanego zewnętrznie. To inna kategoria ryzyka, nawet jeśli na fakturze widnieje ta sama nazwa.
Ta inwentaryzacja nie powinna stać osobno od resztу zarządzania AI (AI-governance) w organizacji. Ta sama klasyfikacja, która stosowana jest do narzędzi zbudowanych wewnętrznie lub do instalacji testowej, która nigdy nie została wyłączona, powinna być zastosowana również do tego, co wprowadzają dostawcy. Jeden przegląd, jedna skala ryzyka, niezależnie od tego, czy AI została zbudowana wewnętrznie, przyniesiona przez pracownika, czy dodana przez dostawcę bez ogłoszenia.
Gdy jasne jest, jaka AI wchodzi przez dostawców, powstaje kolejne pytanie, wykraczające poza samo ryzyko: co ta AI faktycznie robi z pracą, którą obecnie wykonują ludzie, i gdzie to się pokrywa z zadaniami, które i tak kwalifikują się do automatyzacji. Skan pracy FTE TO AI wylicza dla każdego zadania, jaką część pracy można przejąć przez AI, niezależnie od tego, który dostawca lub system to ostatecznie wykonuje. Dzięki temu inwentaryzacja zaczynająca się od ryzyka staje się użyteczna również dla pytania, które nadchodzi później: nie tylko co działa, ale co ta praca faktycznie jest warta.
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.