Sektor ICT ma pozycję, jakiej nie ma żaden inny sektor: tutaj AI nie jest tylko używana, tutaj jest ona również budowana, integrowana i odsprzedawana. Programista, który podłącza model językowy do aplikacji, konsultant, który wbudowuje funkcję AI w projekt klienta, zespół, który dostraja model open-source — to nie są wyjątki, to codzienna praca. Relacja między tym, co decyduje sama organizacja, a tym, co dodaje sam pracownik lub zespół, w tym sektorze wygląda inaczej niż w banku czy firmie budowlanej. Gdzie w innych sektorach AI jest dodatkiem do istniejących procesów, w sektorze ICT AI jest często częścią samego produktu. To oznacza, że governance nie dotyczy tylko wewnętrznych narzędzi, ale również tego, co znajduje się w oprogramowaniu dostarczanym stronom trzecim.
W wielu sektorach dział IT ma wgląd w to, co działa. W sektorze ICT to założenie jest słabsze niż gdzie indziej, właśnie dlatego, że praktycznie każdy sam posiada wiedzę techniczną potrzebną do uzyskania klucza API, pobrania modelu lub wbudowania funkcji AI w bazę kodu, bez wniosku, licencji czy procesu zatwierdzania. Deweloper, który używa modelu językowego do generowania kodu, architekt, który testuje agenta AI w środowisku testowym, zespół sprzedaży, który buduje demo z zewnętrznym modelem — te wybory są podejmowane na poziomie projektu, nie na poziomie zarządu. Inwentaryzacja, która zaczyna się od zakupionych licencji, przez to pomija znaczną część tego, co faktycznie się dzieje. Pytanie nie brzmi, czy istnieje shadow AI, ale ile środowiska produkcyjnego już na niej się opiera, bez tego, że ktokolwiek to udokumentował.
Techniczne środki do wykrywania użycia AI istnieją, ale często widzą tylko to, co przechodzi przez sieci firmowe i zarządzane urządzenia. W sektorze, w którym wiele pracy odbywa się we własnych środowiskach programistycznych, na kontach osobistych i w projektach klientów z własną infrastrukturą, to daje ograniczony obraz. Najbardziej pełna informacja pochodzi od osób wykonujących pracę. To działa tylko wtedy, gdy pytanie zadaje się bez konsekwencji: ktoś, kto wie, że szczera odpowiedź prowadzi do sankcji, nie odpowie szczerze. Jak zapobiec temu, że pracownicy używają narzędzia, którego nikt nie zatwierdził nie zaczyna się więc od kontroli, ale od zaproszenia do zgłoszenia tego, co już się dzieje. To inna kolejność niż ta, do której przyzwyczajona jest większość organizacji, a w sektorze ICT ta kolejność jest szczególnie ważna, ponieważ nieufność między zespołami programistycznymi a działami compliance często już tu istnieje.
Nie każde użycie AI w sektorze ICT wymaga tej samej uwagi. Model, który podsumowuje wewnętrzną dokumentację, jest inny niż model, który współdecyduje o prawach dostępu lub który działa jako część dostarczonego produktu u klienta. Klasyfikacja według roli i poziomu ryzyka nie jest więc czymś, co dzieje się jednorazowo, ale czymś, co musi nadążać za tym, co zespół buduje. To inna dynamika niż w sektorach o bardziej stabilnych procesach, jak można przeczytać w opisach governance w sektorze usług finansowych czy sektorze energetycznym, gdzie zastosowania AI zazwyczaj pozostają w ramach stałej struktury operacyjnej. W sektorze ICT zastosowanie czasem zmienia się szybciej, niż klasyfikacja jest w stanie nadążyć, co znaczy, że sama struktura governance musi mieć miejsce na ponowną ocenę, nie tylko na jednorazowe zatwierdzenie.
Ryzyko, które w sektorze ICT nabiera własnego charakteru, to korzystanie z darmowych lub publicznych narzędzi AI do pracy, która w rzeczywistości jest poufna: kod źródłowy, dane klientów, wewnętrzna architektura, warunki umów. Deweloper, który szybko sprawdza fragment kodu za pomocą publicznego modelu, nie myśli o tym, co się dzieje z tymi danymi wejściowymi. Jak zapobiec temu, że dane firmowe trafiają do darmowego okna czatu opisuje ten mechanizm, i jest to w tym sektorze bardziej istotne niż w większości innych, ponieważ dane, które wyciekają, to często nie tylko dane osobowe, ale również własność intelektualna i kod klienta. Struktura governance, która niczego na ten temat nie ustala, pozostawia ryzyko przy indywidualnym pracowniku, podczas gdy narażenie leży po stronie organizacji.
Dyrektor lub General Counsel w sektorze ICT często już ma ramy ryzyka dla bezpieczeństwa informacji, jakości oprogramowania i zarządzania dostawcami. Governance AI działa lepiej, gdy nawiązuje do tej istniejącej struktury, niż gdy staje się osobnym procesem, którego nikt nie rozpoznaje. Dotyczy to tego sektora silniej niż sektorów takich jak sektor nieruchomości czy budownictwo, gdzie governance AI często wciąż zaczyna się od czystej karty. W sektorze ICT zazwyczaj już istnieje język ryzyka; zadaniem jest rozszerzenie tego języka, a nie jego zastąpienie.
Responsible AI Scan mapuje to, co w organizacji działa w zakresie AI, w tym to, co powstało poza oficjalną listą, i łączy to z klasyfikacją według roli i poziomu ryzyka. Wynikiem jest zestaw governance, który nawiązuje do istniejącej struktury, a nie nowe ramy obok niej. Narzędzie wspierające ten proces jest jeszcze w budowie. Kto chce z tego skorzystać, może zapisać się na listę oczekujących; na tym etapie nic jeszcze nie jest dostarczane poza tym zapisem.
Gdy widoczne jest już, jakie zastosowania AI istnieją i jaki poziom ryzyka jest z nimi związany, naturalnie następuje kolejne pytanie: jaka część pracy wykonywanej obecnie jeszcze przez ludzi jest odpowiednia do przekazania tym zastosowaniom. To inne pytanie niż governance, na które odpowiada skan pracy FTE TO AI, który dla każdego zadania wylicza, jaka część pracy może zostać przejęta przez AI.
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.