Zabezpieczenia AI w przedsiębiorstwach mogą mieć większe znaczenie niż rozwój najbardziej zaawansowanych modeli

Zapomnijmy o wyścigu po najbardziej zaawansowaną AI. Klienci domagają się od przedsiębiorstw większych zabezpieczeń dotyczących AI, z której już korzystają, a doświadczenia związane z PCI DSS stanowią przydatny wzór.

Okres pobłażliwości regulatorów wobec AI dobiegł końca. Ostatnie ujawnione informacje wywołały dyskusje o spowolnieniu rozwoju najbardziej zaawansowanych modeli i wprowadzeniu obowiązkowych zabezpieczeń. Jednym z nielicznych punktów zgody jest to, że zabezpieczenia powinny działać poza modelami i podlegać niezależnej weryfikacji.

Trwa dyskusja o tym, co wydarzy się dalej, ale regulatorzy podejmują działania. Unijny akt w sprawie sztucznej inteligencji stopniowo wprowadza obowiązki w zakresie bezpieczeństwa, w tym odpowiedzialność nabywców. W Stanach Zjednoczonych ramy zarządzania ryzykiem związanym z AI opracowane przez NIST są przyjmowane jako standard należytej staranności. Na całym świecie OWASP: 10 najważniejszych zagrożeń dla aplikacji LLM stało się powszechnym punktem odniesienia podczas przeglądów bezpieczeństwa, a certyfikacja ISO/IEC 42001 pojawia się w dokumentach przetargowych.

Oznacza to, że odpowiedzialność nie spoczywa wyłącznie na twórcach modeli. Obowiązki i ryzyko związane z bezpieczeństwem dotyczą także przedsiębiorstw korzystających z już udostępnionych modeli, zwłaszcza w zastosowaniach wysokiego ryzyka. Błędne odpowiedzi w kwestionariuszu bezpieczeństwa klienta lub w odpowiedzi na zapytanie ofertowe mogą zahamować transakcję B2B.

PCI DSS wskazuje drogę

Na szczęście już to przerabialiśmy. Dwadzieścia lat temu bezpieczeństwo aplikacji internetowych opierało się głównie na okresowych audytach kodu, analizach statycznych i dyscyplinie programistów. Następnie wymóg 6.6 PCI DSS, opublikowany w 2006 roku i egzekwowany od 2008 roku, zobowiązał organizacje przetwarzające dane posiadaczy kart do przeglądu całego kodu aplikacji pod kątem podatności albo wdrożenia zautomatyzowanych zabezpieczeń technicznych. Później zrezygnowano z możliwości przeglądu kodu i wymagano stosowania zabezpieczeń technicznych.

PCI DSS nie zaczęło jednak obowiązywać jako prawo. Zaczęło się od standardu umownego, który przekształcił rynek — prawdopodobnie szybciej, niż zrobiłoby to ustawodawstwo, ponieważ umowy zmieniają się szybciej niż przepisy państwowe.

Podobnie organizacje odczuwają dziś presję, by wprowadzać zabezpieczenia dla wdrożonej AI — nie ze strony regulatorów, lecz klientów i partnerów, za pośrednictwem kwestionariuszy bezpieczeństwa, zapisów w zapytaniach ofertowych i wymogów polis ubezpieczeniowych.

Rozwiąż problem operacyjny, a zgodność z przepisami przyjdzie później

Sprostanie tej presji może być trudne, ponieważ ład korporacyjny w obszarze AI to nie tylko kwestia zasad. Chodzi także o ciągłe gromadzenie dowodów technicznych.

Wiele przedsiębiorstw, z którymi rozmawiam, korzysta na produkcji z sześciu lub więcej modeli, często łącząc je ze sobą lub orkiestrując ich działanie tak, by wynik jednego modelu stanowił dane wejściowe dla kolejnego. Wyobraźmy sobie, że w takich warunkach trzeba wykazać egzekwowanie dowolnej pojedynczej zasady w całym systemie — na przykład zapobiegania umieszczaniu danych osobowych (PII) w wynikach modeli. Ręczne audytowanie wielu modeli skonfigurowanych niezależnie od siebie pochłaniałoby czas programistów. Ponadto większość organizacji ma trudności z niezatwierdzonym i obarczonym wysokim ryzykiem korzystaniem z AI, na przykład gdy pracownicy wklejają wrażliwe dane do konsumenckich narzędzi AI albo dostawcy SaaS po cichu włączają nowe funkcje AI. Odpowiedzialność spoczywa jednak w całości na przedsiębiorstwie.

W tak trudnych warunkach wymagania można sprowadzić do jednego prostego zadania: wykazać, że można stale ograniczać dane wejściowe i wyjściowe modeli, a jednocześnie rejestrować tę aktywność na potrzeby weryfikacji. Gdy aplikacje wywołują modele, agenci uruchamiają narzędzia, a modele wykonują działania lub uruchamiają przepływy pracy, kontrolować należy samo działanie — wywołanie narzędzia, żądanie API czy uruchomienie przepływu pracy.

Przenieś zabezpieczenia na ścieżkę wnioskowania

To działanie stanowi punkt egzekwowania zabezpieczeń, który specjaliści od bezpieczeństwa aplikacji od 20 lat tworzą z myślą o ruchu aplikacyjnym. Zwłaszcza gdy wnioskowanie odbywa się za pośrednictwem współdzielonej infrastruktury, ścieżka wnioskowania staje się idealnym punktem kontroli obejmującym różne modele, a nawet niezatwierdzone korzystanie z AI. Ruch związany z wnioskowaniem AI należy dostarczać, kontrolować, uwierzytelniać i nadzorować tak jak każdą inną istotną interakcję z aplikacją, uwzględniając źródło ruchu i jego cel. W przeciwieństwie do ręcznego audytowania nadzór nad ruchem związanym z wnioskowaniem będzie skalowalny.

Jak zacząć

Biorąc pod uwagę kierunek zmian regulacyjnych, organizacje powinny już teraz podjąć trzy działania:

1. Określ zakres swojej odpowiedzialności — od interfejsów API SaaS i hostowanych punktów końcowych po nieautoryzowane rozwiązania AI.
2. Oddziel zasady bezpieczeństwa i ich egzekwowanie od modeli, a następnie umieść je na ścieżce wnioskowania.
3. Zadbaj o to, by ścieżki audytowe były generowane poza kontrolą modeli i agentów, które — jak wykazano — próbują zmieniać zapisy dotyczące własnych działań.

Nadal ustala się, co można uznać za odpowiedni monitoring i egzekwowanie zabezpieczeń, ale zespoły operacyjne i bezpieczeństwa w Twoim przedsiębiorstwie wiedzą, co da się rzeczywiście egzekwować, jakie koszty pod względem opóźnień i złożoności wiążą się z kontrolą oraz w jakich sytuacjach dobrze pomyślana zasada może przynieść niewłaściwy rezultat. Zaangażuj je już teraz. Ryzyko i obowiązki związane z korzystaniem z AI są realne, a Twoi klienci i członkowie kadry kierowniczej niewątpliwie bardziej przejmują się tym, z czym mierzą się dziś, niż zagrożeniami ze strony modeli najnowszej generacji, które mogą pojawić się jutro.