Dostawca dodaje funkcję, która pod maską działa na modelu językowym lub interfejsie API strony trzeciej. Dla dostawcy to aktualizacja produktu, a nie zdarzenie wymagające zgłoszenia. Notatki o wydaniu wspominają o nowym przycisku, nie o technologii, która za nim stoi. Państwa organizacja już korzysta z tego oprogramowania, umowa została podpisana na podstawie starej funkcjonalności, a zmiana nie trafia przez zakupy ani bezpieczeństwo — te działy widzą jedynie to, co dzieje się przy nowych zakupach, a nie to, co istniejący produkt po cichu zyskuje.
Wzorzec jest taki sam jak przy rozszerzeniu przeglądarki z dostępem do poczty: dostęp i funkcja istnieją już, zanim ktokolwiek je oceni. U dostawcy dystans jest jednak większy — nie mogą państwo zajrzeć do kodu źródłowego i muszą polegać na tym, co dostawca mówi, albo nie mówi.
Nie ma momentu, w którym to się sam zgłasza. Pracownik korzysta z nowej funkcji, bo jest przydatna, nie dlatego, że rozpoznaje w niej element AI. Dostawca nie ma motywacji, by aktywnie to zgłaszać, dopóki nikt o to nie zapyta: nie przynosi to przychodu, a może wywołać pytania. A szansa, że sami na to natrafią, jest niewielka, o ile nie dojdzie do incydentu albo okresowa kontrola tego nie zauważy.
Przypomina to w ten sposób wewnętrzny pilotaż, który został zapomniany: podobnie jak przy testowej instalacji, która nigdy nie została wyłączona, nie brakuje tu złej woli, lecz momentu, w którym ktoś zadaje właściwe pytanie. U dostawcy dochodzi do tego jeszcze zależność od jego woli udzielenia odpowiedzi.
Punktem wyjścia nie jest wymuszanie umowy prawnie przy pierwszej wątpliwości, lecz najpierw ustalenie, co się dzieje. Zaczyna się to od zadawania pytań dostawcy: które części produktu korzystają z AI, jakie dane tam trafiają i czy coś się zmieniło od podpisania umowy. Dostawcy, którzy mogą odpowiedzieć bez konsekwencji, robią to raczej zgodnie z prawdą niż dostawcy, którzy przypuszczają, że szczera odpowiedź zagrozi umowie.
Ta sama logika obowiązuje wewnątrz organizacji: pracownicy korzystający z narzędzia, o którym nikt nie wie, że zawiera AI, zgłoszą to tylko wtedy, gdy zgłoszenie nie skończy się karą. Jak to zorganizować, opisano w pracownikach korzystających z narzędzia, którego nikt nie zatwierdził. Przy dostawcy zasada działa tak samo: pytanie bez posądzenia otrzyma inną odpowiedź niż pytanie odczytane jako wstęp do sankcji.
Gdy już wiadomo, co dostawca dodał, kolejne pytanie nie jest prawne, lecz funkcjonalne: jaką rolę odgrywa ten element AI w procesie, jaki jest poziom ryzyka i co powinno zostać w związku z tym udokumentowane. Te same pytania stawiają państwo wobec każdego zastosowania AI, którego sami używają, niezależnie od tego, czy trafiło ono do organizacji przez dostawcę, czy przez pracownika korzystającego z darmowego narzędzia — zob. również dane firmowe trafiające do darmowego okna czatu. To, co należy udokumentować dla każdego zastosowania, zależy od tego, co ono robi i z jakimi danymi, a nie od tego, skąd pochodzi. Przegląd tego, co jest w tym istotne, znajduje się na stronie co należy udokumentować dla każdego zastosowania.
Dostawca, który dodaje AI bez zgłoszenia, nie powinien więc być traktowany jako odrębny incydent, lecz włączony do inwentaryzacji, którą już budują państwo dla całej organizacji. Jak taka inwentaryzacja jest budowana w praktyce — łącznie z tym, jak umieścić w niej dostawców — opisano na stronie jak zbudować inwentaryzację AI.
To nie jest powód do prawnej ofensywy wobec każdego dostawcy, który czegoś nie zgłosił. Stwierdzenie naruszenia umowy to inna kwestia niż stwierdzenie ryzyka i te dwie rzeczy nie idą automatycznie w parze: dostawca może nie zgłosić czegoś, choć zastosowanie nie niesie wysokiego ryzyka, i odwrotnie. Pierwszym krokiem jest ocena ryzyka, nie kwestia winy. Kto zaczyna od sankcji, otrzyma od dostawców w przyszłości mniej informacji, nie więcej.
Gdy już wiadomo, jakie elementy AI działają w organizacji za pośrednictwem dostawców, pracowników czy własnych inicjatyw, pojawia się inne pytanie: co to oznacza dla samej pracy. Nie każde zastosowanie AI, które się pojawia, robi faktycznie coś użytecznego w procesie, w którym się znajduje — i nie każdy proces, który obecnie przebiega ręcznie, jest z definicji lepszy bez AI. Skan pracy FTE TO AI wylicza dla każdego zadania, jaką część pracy można zasadnie przejąć przez AI, niezależnie od tego, jak ta AI się tam znalazła. Dzięki temu inwentaryzacja, którą teraz budują, staje się nie tylko narzędziem governance, ale też punktem wyjścia do określenia, gdzie AI faktycznie robi różnicę.
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.