Vin Sharma, współzałożyciel i dyrektor generalny Vijil – cykl wywiadów

Vin Sharma jest współzałożycielem i dyrektorem generalnym Vijil. Ma ponad 30 lat doświadczenia w obszarach cyberbezpieczeństwa, otwartego oprogramowania, chmury obliczeniowej i infrastruktury AI. Zanim założył firmę, kierował pracami inżynieryjnymi nad głębokim uczeniem w AWS na potrzeby Amazon SageMaker i Amazon Bedrock, rozwijał infrastrukturę centrów danych w Intel oraz pełnił funkcje w obszarze produktów i inżynierii w Hewlett-Packard. Karierę rozpoczął od zautomatyzowanych testów typu red team dla zaufanych systemów UNIX. To doświadczenie wpływa na jego podejście do zapewniania niezawodności, bezpieczeństwa i ochrony agentów AI wykorzystywanych w przedsiębiorstwach.

Vijil zapewnia infrastrukturę zaufania dla agentów AI wykorzystywanych w przedsiębiorstwach, pomagając organizacjom oceniać ich zachowanie, egzekwować mechanizmy kontroli i zwiększać odporność na każdym etapie cyklu życia agentów. Podejście firmy łączy testowanie, bezpieczeństwo i ciągłą informację zwrotną, aby dostosować działanie agentów do zamierzonego celu i polityk organizacji. W tym wywiadzie Sharma opowiada o tym, jak definiować i mierzyć zaufanie, dlaczego testowanie agentów różni się od konwencjonalnego zabezpieczania oprogramowania oraz jakiego nadzoru potrzebują przedsiębiorstwa w miarę uzyskiwania przez agentów coraz większej autonomii.

Przez ponad 30 lat pracował Pan w firmach takich jak AWS, Intel i Hewlett-Packard, zanim założył Pan Vijil. Co ostatecznie przekonało Pana, że zaufanie do AI i jej bezpieczeństwo to na tyle poważny, nierozwiązany problem, by zbudować wokół niego firmę?

Zanim 30 lat temu dołączyłem do startupu z branży bezpieczeństwa, studiowałem na studiach magisterskich AI i uczenie maszynowe. Od tamtej pory pracowałem w zespołach produktowych, które wdrażały zabezpieczenia klasy wojskowej w systemach operacyjnych opartych na Unixie i Linuksie, tworzyły bezpieczne serwery WWW na potrzeby bankowości internetowej, rozwijały zaufane środowiska wykonawcze dla chmury obliczeniowej, integrowały szyfrowanie z platformami analityki danych, a ostatnio zatoczyłem pełne koło, wracając do budowania gotowych do wdrożeń w przedsiębiorstwach usług AI/ML w AWS. Ta droga utwierdziła mnie w przekonaniu, że wbudowanie zaufania w system inteligentny jest trudniejsze niż zbudowanie samego inteligentnego systemu. Branża AI wydaje się powszechnie skupiona na zwiększaniu możliwości agentów, ale uważam, że powinniśmy przeznaczać równie wiele zasobów na wbudowywanie w nich skalowalnych mechanizmów nadzoru i kontroli. Bez wskaźników i mechanizmów dostosowanych do potrzeb konkretnych organizacji początkowa fala entuzjastycznych wdrożeń rozbije się o mielizny ryzyka i zwrotu z inwestycji, ponieważ firmy nie będą w stanie udowodnić, że agenci działają w ich najlepszym interesie.

Vijil opiera się na założeniu, że wielu agentów AI nigdy nie trafia do środowiska produkcyjnego, ponieważ przedsiębiorstwa nie potrafią odpowiednio zweryfikować ich niezawodności, bezpieczeństwa i ochrony. Gdzie dostrzega Pan największe luki w zaufaniu, gdy firmy przechodzą od prototypów AI do wdrożeń produkcyjnych?

Wąskim gardłem utrudniającym wdrażanie kolejnych agentów o coraz większej autonomii jest to, czy organizacje potrafią określić zamierzone zachowanie agentów i sprawdzić, czy działają zgodnie z tymi założeniami. Co więcej, muszą móc robić to w skali i tempie, w jakich działają agenci. Wydaje się więc logiczne, że potrzebujemy sposobu, by agenci mogli mierzyć i modyfikować zachowanie innych agentów. Dwie największe luki dotyczą tego, co mierzyć (co oznacza dobre działanie agentów) oraz co modyfikować (które elementy systemu agenta dostroić, aby uzyskać zachowanie zamierzone przez jego mocodawcę: model i jego parametry, prompt systemowy, instrukcje użytkownika, środowisko wykonawcze agenta czy graf systemów wieloagentowych).

Jak Vijil definiuje i mierzy „zaufanie” do agenta AI? Które sygnały lub testy porównawcze mają największe znaczenie przy ocenie, czy agent jest gotowy do działania w środowisku przedsiębiorstwa?

Definiujemy zaufanie jako oczekiwaną korzyść z powierzenia zadań autonomicznemu agentowi, pomniejszoną o ryzyko, że sprzeniewierzy się naszym intencjom. Oznacza to, że można ufać agentowi, jeśli działa prawidłowo w zwykłych, zakłóconych i wrogich warunkach, a w razie awarii ogranicza jej zasięg. Zaufanie możemy mierzyć w trzech wymiarach: niezawodności, bezpieczeństwa i ochrony. Agenci są niezawodni, gdy działają zgodnie z oczekiwaniami w różnych warunkach; są bezpieczni, gdy działają zgodnie z oczekiwaniami w warunkach wrogich; a zapewniają ochronę, gdy potrafią ograniczać ryzyko biznesowe, prawne i techniczne.

Agenci AI mogą zachowywać się nieprzewidywalnie, ponieważ łączą modele, narzędzia, źródła danych, pamięć i systemy zewnętrzne. Czym testowanie agenta różni się od tradycyjnych testów bezpieczeństwa aplikacji lub konwencjonalnej oceny modelu?

Tradycyjne oprogramowanie zawodzi w sposób, który jest już dobrze poznany: mówiąc ogólnie, nie radzi sobie z nieprawidłowymi danymi wejściowymi, ma słabości w logice i projekcie systemu, błędy w implementacji, ukryte podatności na ataki oraz niezamierzone skutki uboczne generowanych wyników. Testowanie pod kątem takich awarii jest z natury przewidywalne. Agenci znacznie poszerzają obszar potencjalnych awarii — do tego stopnia, że ocena modeli, testy jednostkowe i integracyjne, testy bezpieczeństwa aplikacji, testy penetracyjne oraz kontrole zgodności nie są już w stanie go objąć. Aby testować nowe obszary ryzyka związane z agentami, potrzebujemy nowych wskaźników i mechanizmów oceniających zachowanie agenta w odniesieniu do jego celu określonego przez mocodawcę, profili jego użytkowników oraz polityk organizacji, branży i regionu, w których działa.

Twoje doświadczenie obejmuje kierowanie pracami inżynieryjnymi nad głębokim uczeniem dla Amazon SageMaker i Amazon Bedrock. Które wnioski z budowania infrastruktury AI w AWS w największym stopniu wpłynęły na Twoje podejście do bezpieczeństwa i niezawodności agentów w Vijil?

Najważniejszy wniosek był taki, że wykrywanie problemów z niezawodnością, bezpieczeństwem i zgodnością usług na wczesnym etapie cyklu rozwoju było znacznie skuteczniejsze i wydajniejsze niż znajdowanie ich tuż przed premierą, co było tradycyjną praktyką, a tym bardziej niż odkrywanie ich po wdrożeniu usługi, gdy oznaczało to pobudkę z powodu telefonów informujących o awarii.

Vijil koncentruje się nie tylko na testowaniu agentów przed wdrożeniem, lecz także na ich ochronie i nieustannym doskonaleniu już w środowisku produkcyjnym. Jakie rodzaje ryzyka ujawniają się dopiero wtedy, gdy agent zaczyna wchodzić w interakcje z prawdziwymi użytkownikami, danymi i systemami przedsiębiorstwa?

Rzeczywistość ma nieograniczoną zdolność zaskakiwania. A zaskoczony agent jest bardziej podatny na błędy. Nikogo nie martwi agent, który popełni błąd przy tworzeniu mema. Agent zaprojektowany z myślą o wspieraniu lub zastępowaniu doradcy finansowego, asystenta prawnego, adwokata, pielęgniarki, lekarza, pacjenta lub dowolnego specjalisty w branży, w której trzeba wykazać działanie zgodne z obowiązkiem powierniczym, nie może funkcjonować, jeśli poziomy tolerancji nie zostaną ściśle określone i uważnie monitorowane, a zachowanie agenta szybko przywrócone do właściwego stanu.

W miarę jak przedsiębiorstwa wdrażają coraz bardziej autonomicznych agentów, którzy mogą podejmować działania, a nie tylko generować odpowiedzi, jak powinien ewoluować model bezpieczeństwa? Czy tradycyjne rozwiązania, takie jak uprawnienia, tożsamość i kontrola dostępu, są wystarczające?

Nie. Gdy agenci stają się uczestnikami działań organizacji, należy nadawać im unikatowe, weryfikowalne tożsamości i przypisywać role, które określają zarówno ich zachowanie, jak i komponenty funkcjonalne (narzędzia z uprawnieniami dostępu do zasobów), a także obejmować je politykami obowiązkowej kontroli dostępu. Trzeba stale monitorować, czy nie odchodzą od zamierzonego celu, i odpowiednio nimi kierować, aby zachowały odporność na ataki.

Vijil przeszło od rundy zalążkowej o wartości 6 mln dolarów do rundy serii A o wartości 17 mln dolarów, budując przy tym zespół założycielski liczący około 20 osób i osiągając pierwszy 1 mln dolarów rocznych przychodów cyklicznych. Jakie decyzje miały największe znaczenie dla przejścia od wczesnej koncepcji technicznej do komercyjnego wdrożenia?

Od początku zdecydowaliśmy się zbudować warstwę zaufania, która integruje się z wybraną przez klienta platformą, ale przewidywaliśmy, że przedsiębiorstwa będą coraz częściej oczekiwać większych możliwości dostosowania, bardziej szczegółowej kontroli i niższych kosztów w przypadku systemów wieloagentowych opartych na modelach otwartych. Długofalowa strategia budowania warstwy platformowej zamiast pojedynczego produktu daje nam przewagi, ale wiąże się też z trudnościami: znalezienie przedsiębiorstw gotowych do zarządzania agentami na dużą skalę nie jest tak łatwe jak sprzedaż usługi polegającej na przeniesieniu systemu bez zmian.

Karierę rozpocząłeś w 1995 roku od tworzenia zautomatyzowanych testów red team dla zaufanych systemów UNIX. Jak przez niemal trzy dekady zmieniły się zasady testów red team, gdy testowanym systemem jest agent AI zdolny do rozumowania, adaptacji i korzystania z zewnętrznych narzędzi?

Historycznie testy red team polegały na sprawdzaniu zabezpieczeń organizacji w obliczu skoordynowanego ataku. Ogólne zasady pozostają aktualne. Nadal trzeba przeprowadzać skoordynowane ataki w kontrolowanych warunkach, aby wykrywać słabe punkty badanej organizacji. Jednak etap, w którym ćwiczenia red team opierały się na gotowych scenariuszach służących do testowania systemów oprogramowania, już nie wystarcza, ponieważ agenci AI nie są deterministycznym oprogramowaniem — zaprojektowano ich tak, by dostosowywali się do otoczenia, dlatego tego samego ataku nie da się przewidywalnie powtórzyć. Uważam, że agentów należy traktować jak korporacje. Z tego wynika, że testowanie agentów przez zespoły red team musi uwzględniać dostosowanie do ich celów, badanie, czy odchodzą od intencji użytkowników, oraz sprawdzanie, czy są skłonni i zdolni do omijania zasad obowiązujących w ich środowisku.

Czy w przyszłości niezależne testowanie i mierzalne standardy zaufania dla agentów AI staną się warunkiem ich wdrażania w przedsiębiorstwach? Co musi się wydarzyć w całej branży, aby taki poziom wiarygodności stał się standardową praktyką?

Obecnie twórcy oceniają możliwości agentów, zespoły red team sprawdzają ich odporność na wstrzykiwanie poleceń i próby jailbreaku, a zespoły GRC dopiero zaczynają testować ich zgodność z przepisami. Bardzo niewiele organizacji wdraża system ciągłej weryfikacji zachowania agentów, działający w tle przez cały cykl ich życia, mimo zmian modeli, narzędzi, zasobów, przepływów pracy i środowiska docelowego. Co jeszcze ważniejsze, Vijil wyróżnia się tym, że pomaga przedsiębiorstwom powiązać rzeczywiste zachowanie agenta w środowisku produkcyjnym z jego specyfikacją w ramach pętli informacji zwrotnej, która stale doskonali agenta. Agenci, którzy przetrwają ataki, to ci, którzy potrafią się dostosować i zachować odporność.

Dziękujemy za ciekawy wywiad. Czytelnicy, którzy chcą dowiedzieć się więcej o testowaniu, ochronie i nieustannym doskonaleniu agentów AI dla przedsiębiorstw, powinni odwiedzić Vijil.