Przezwyciężanie podejścia „AI to magia”: dlaczego poznanie zasad działania modeli AI musi stać się priorytetem całej firmy

W obliczu ostrzeżeń przed wymykającymi się spod kontroli agentami AI pewien programista niedawno dał agentowi programistycznemu wolną rękę na komputerze bez zdalnej kopii zapasowej. Usunął 48 000 plików w niecałe dwie minuty.

Takie sytuacje dobitnie przypominają, że wdrażanie agentów AI wiąże się z ryzykiem; samo dodanie ludzkiego recenzenta na którymś etapie złożonego procesu nie wystarczy, by uznać go za bezpieczny. Niektóre procesy nie wymagają żadnej interwencji, inne zaś potrzebują znacznie ściślejszej kontroli. Poprawienie literówki i usunięcie tysięcy plików wiążą się z zupełnie innym poziomem ryzyka, dlatego zakres nadzoru powinien odpowiadać temu, co rzeczywiście jest zagrożone.

Organizacje muszą lepiej rozpoznawać momenty, w których ludzka ocena rzeczywiście ma znaczenie, zwłaszcza gdy działanie może mieć poważne skutki lub trudno je odwrócić. A kiedy agenci popełniają błędy, środowisko powinno ograniczać ich zasięg.

AI nie działa deterministycznie, lecz probabilistycznie

Przede wszystkim każdy pracownik, który bezpośrednio lub pośrednio uczestniczy w tworzeniu oprogramowania, musi zdobyć podstawową wiedzę o tym, jak modele AI przetwarzają informacje. To niemałe zadanie: wymaga zaangażowania w edukację zespołów, a z czasem powinno stać się priorytetem całej firmy.

Kiedy ktoś po raz pierwszy zaczyna korzystać z AI, może się to wydawać magią. Wpisujesz zdanie i nagle prowadzisz rozmowę. Podstawowa wiedza o tym, jak naprawdę działają modele i proces ich trenowania, jest ważna przy ustalaniu firmowej polityki dotyczącej bezpieczeństwa i produktywności w obszarze AI. Sieci neuronowe, tokenizacja, leżąca u ich podstaw analiza statystyczna oraz sposób, w jaki prowadzi ona do uzyskania wyników, stanowią istotną okazję do edukacji wszystkich pracowników firmy.

Duże modele językowe nigdy nie będą generować wyników w sposób deterministyczny. Ich wyniki mają charakter probabilistyczny. W przypadku typowego oprogramowania, gdy podajesz dane wejściowe, możesz się spodziewać określonych wyników, na przykład A, B albo C. AI może jednak zwrócić F, znak & albo opis kota w okularach przeciwsłonecznych.

Wyników probabilistycznych nie da się testować w typowy sposób. Potrzebna jest metoda testowania, która pozwala szybko wprowadzać zmiany, analizować, rozumieć i pobierać kontekst, by wychwytywać elementy probabilistyczne i rozpoznawać problemy, które mogą powodować. W zależności od skali i ryzyka takie testy może prowadzić AI albo człowiek z odpowiednią wiedzą. Udział człowieka w procesie jest najbardziej przydatny na samym początku, kiedy można określić problem do rozwiązania, a następnie ponownie ocenić wyniki na końcu.

Ponieważ programiści najlepiej mogą obserwować zmienne i typowe praktyki związane z tym, jak wewnętrzne systemy AI ich organizacji generują odpowiedzi na podstawie danych wejściowych, mogą odegrać ważną rolę w kształtowaniu edukacji dotyczącej AI w swoich firmach i zadbać o to, by wszyscy rozumieli różnicę między determinizmem a probabilizmem w AI oraz wiedzieli, dlaczego ma ona znaczenie. Celem jest odejście od przekonania, że korzystanie z AI przypomina magię i można z zadowoleniem przyjąć dowolny wynik. Organizacje powinny zamiast tego dążyć do odczarowania modeli używanych w firmie oraz przedstawienia tego, jak są wykorzystywane, jakie problemy mogą się pojawić, jak są sprawdzane i jakie wyniki przynosi ten proces.

Mechanizmy zabezpieczające należą do infrastruktury, nie do modelu

Kiedy obalimy mit „magii” AI i rozpoczniemy projekt oparty na AI, niezbędne jest wdrożenie przejrzystej polityki audytu, która pozwoli upewnić się, że wszystko przebiega zgodnie z założeniami. Dzięki temu, jeśli projekt przyniesie „zły” lub niezadowalający wynik, osoba odpowiedzialna będzie mogła prześledzić podjęte działania i zapobiec ponownemu wystąpieniu problemu. Takie podejście przynosi korzyści również wtedy, gdy wyniki okażą się lepsze od oczekiwanych, ponieważ podjęte działania można powtórzyć i zastosować w innych projektach lub zespołach.

Systematyzacja tego procesu jest szczególnie ważna w większych firmach, gdzie w każdym zespole może pracować kilkudziesięciu programistów, a w ciągu dnia setki osób mogą wprowadzać zmiany w kodzie. AI potrafi bardzo szybko wykonywać wiele zadań, a gdy coś pójdzie nie tak, potrzebny jest system pozwalający dokładnie ustalić, na którym etapie wystąpił problem. Wystarczy spojrzeć na agentów OpenAI, którzy tego lata włamali się do systemów Hugging Face. OpenAI sprawdzało, jak skutecznie jego modele potrafią wykorzystywać luki w oprogramowaniu, korzystając z testu porównawczego o nazwie ExploitGym. Na potrzeby testu celowo złagodzono odmowy modeli dotyczące ofensywnych działań cybernetycznych. Jedyną drogą wyjścia z piaskownicy był serwer proxy pakietów. Modele znalazły nieznaną wcześniej lukę w tym serwerze, wydostały się z piaskownicy i przez ponad dwa dni przeszukiwały produkcyjne systemy Hugging Face w poszukiwaniu odpowiedzi do testu.

Nagłówki nazwały to zbuntowaną AI. Ja nazwałbym to deterministyczną konfiguracją wokół systemu probabilistycznego. OpenAI poleciło modelom przeprowadzić atak hakerski, a potem liczyło na to, że pozostaną na wyznaczonej ścieżce. Twórca testu twierdzi, że modele już wcześniej oszukiwały podczas testu, ale zawsze pozostawały w piaskownicy. Tym razem jedno z nich ją opuściło. Standardowe zabezpieczenia zakładają standardowe zachowanie, ale AI nie musi przestrzegać standardów.

Dlatego bezpieczeństwo AI sprowadza się do dostępu i kontroli egzekwowanych przez środowisko, a nie do dobrego zachowania modelu. Zakładaj, że agent spróbuje otworzyć każde drzwi, i pozostaw otwarte tylko te, których potrzebuje. Agent, który usunął 48 000 plików, miał polecenie pracować na kopiach i nie ruszać oryginałów. Mimo to usunął oryginały. Polecenia to nie zabezpieczenia.

Zarządzanie uprawnieniami agenta przypomina wdrażanie nowego, młodszego programisty. Nie dałbyś mu pierwszego dnia uprawnień administratora do środowiska produkcyjnego. Gdybyś tak zrobił, a on usunąłby twoją bazę danych, nie uznałbyś, że to sprawka genialnego hakera. W przypadku incydentów związanych z bezpieczeństwem, niezależnie od ich skali, trzeba koniecznie ustalić ich pierwotną przyczynę. Czy odpowiada za to model? Czy firma, która go stworzyła? Czy firma, która dała mu dostęp? Niezależnie od przyczyny ostateczną odpowiedzialność ponosi człowiek.

Ważną kwestią, którą trzeba się dziś zająć, jest to, co dzieje się w ukryciu na laptopie programisty. W przeszłości łatwiej było prześledzić przebieg pracy. Programiści pisali kod, sprawdzali go i wdrażali, więc można było jasno ustalić, na którym etapie coś poszło nie tak. Teraz programista może przekazać agentowi zgłoszenie i powiedzieć: „napraw to”. Jeśli praca odbywa się poza czyimkolwiek nadzorem, nie ma czego prześledzić. Każdy etap musi być dokładnie udokumentowany: który agent został uruchomiony, jakiego modelu używał, jakie polecenia mu przekazano, z jakich narzędzi skorzystał i jakie miał wówczas uprawnienia. Jednym ze sposobów na osiągnięcie tego celu jest uruchamianie agentów centralnie, zamiast na poszczególnych laptopach. Najważniejsze, by taki zapis istniał.

Ostatecznie każda firma musi chronić się na wypadek incydentu. Taki zapis powinien zawierać wystarczająco dużo informacji, by przeprowadzić analizę pierwotnej przyczyny i ustalić, który etap oraz jaki kod spowodowały problem.

AI ogromnie zmieniła świat, a procesy biznesowe muszą za tym nadążyć. Aby określić właściwe zabezpieczenia, trzeba lepiej rozumieć procesy związane ze sztuczną inteligencją, testowanie, cykle przeglądów i audytów — zarówno w zespołach programistycznych, jak i w całej firmie.