TRANSKRYPCJA WEBINARU

Bezpieczne tworzenie modeli AI: jak unikać problemów dzięki Secure AI

 

Prelegent: Gabriel Marchwant
Data: 25.02.2025

 

Magdalena Cuper: Witam wszystkich serdecznie na naszym dzisiejszym webinarze „Bezpieczeństwo modeli AI: Jak unikać problemów dzięki AI SAIF Framework”.

Bardzo się cieszę, że dołączyliście i poświęciliście swój czas. Nie wiem w ogóle, jaka jest u was pogoda, u mnie niestety pochmurno, więc mam nadzieję, że jakaś dobra kawka czy herbatka wyciągnięta, żebyśmy się wszyscy mogli pobudzić minimalnie. Gabriel przedstawi nam cudowną prezentację, tak więc poranek spędzimy bardzo przyjemnie.

Zanim przejdziemy do treści, byłabym bardzo wdzięczna o uzupełnienie krótkiej ankiety, a w międzyczasie przedstawię dwie krótkie informacje. Webinar będzie nagrywany i wysłany w ciągu czterech dni roboczych. Jeśli nie zdążymy ze wszystkimi pytaniami, to odpowiedzi na nie uzyskacie w wiadomości z linkiem do nagrania, więc nic się kompletnie nie martwcie, na wszystko uzyskacie informacje.

I już tutaj widzę, że rozpoczęło się głosowanie, tak więc serdecznie dziękuję za wzięcie udziału. Jeszcze chwileczkę poczekamy też na pozostałych uczestników, bo jest 10:02, tak szybko zaczynamy, a często trzeba jeszcze sobie na spokojnie usiąść wygodnie.

 

Agenda i wprowadzenie do wydarzenia

Serdecznie dziękujemy za oddanie głosów. Krótkie przedstawienie: z tymi, co byli z nami, się witamy, a nowych zachęcamy, żeby z nami zostali. FOTC to wiodący dostawca rozwiązań chmurowych. Specjalizujemy się w doradztwie technologicznym, usługach IT, danych i sztucznej inteligencji oraz w usługach zarządzanych. Naszym celem jest dostarczanie kompleksowych rozwiązań, które zapewniają bezproblemową implementację, integrację i wsparcie technologiczne.

Dzisiejszy webinar poświęcony jest Secure AI Framework – podejściu do bezpiecznych modeli AI. Nasz program będzie obejmował:

• Podstawy AI i wpływ na biznes,
• czym jest SAIF i jakie wyzwania rozwiązuje,
• wsparcie Google Cloud w zarządzaniu AI,
• mapę ryzyka i zabezpieczeń AI (omówienie ryzyk i sposobów ich minimalizacji),
• korzyści z wdrożenia SAIF, samoocenę ryzyka AI oraz skuteczne strategie zarządzania.

Widzę, że zbiera się nas bardzo fajna liczba, więc serdecznie dziękuję. Chciałabym też przedstawić naszego eksperta, Gabriela Maranta, który jest Cloud Security Engineerem i ma ponad siedmioletnie doświadczenie w branży bezpieczeństwa. Gabriel specjalizuje się w blue teaming, SecOpsie i zarządzaniu ryzykiem, a od lat śledzi rozwój dużych modeli językowych i jest także pasjonatem aplikacji AI i kryminalistyki.

Serdecznie dziękujemy za wysłuchanie początku, zachęcamy do aktywnego zadawania pytań na czacie. Tak jak wspominałam, na wszystkie pytania odpowiemy – jeżeli nie teraz, to w wiadomości mailowej. Możemy już zaczynać. Gabriel, oddaję tobie głos. Dziękuje ślicznie.

 

Czym jest Secure AI Framework?

Gabriel Marchwant: Cześć, witajcie, witam wszystkich serdecznie. Dziękuję za tak miłe przedstawienie. Myślę, że możemy zaczynać od wyjaśnienia, czym jest problem, który będzie rozwiązywał SAIF, kawałka historii, skąd się w ogóle wziął i wyjaśnienia, czym dokładnie jest Secure AI Framework.

Nasze spotkanie wynika przede wszystkim z tego, że AI rozwija się szybciej niż specjaliści są w stanie nadążyć, regulatorzy także nie są w stanie nadążyć za tym, co się dzieje . Widać to po tym, w jakim tempie Unia Europejska próbuje wdrażać kolejne dyrektywy i prawo mające na celu regulację i ustandaryzowanie tego, w jaki sposób AI ma zostać wdrożone.

Kolejną kwestią jest to, że każdego dnia powstają nowe metody ataków na systemy AI. Sam tytuł prezentacji rozszerzymy nie tylko na modele, ale na bezpieczeństwo całych systemów. Co mam na myśli przez cały system? Nie tylko i wyłącznie model, ale też aplikację stojącą za tym modelem, przechowywane dane oraz infrastrukturę. Dlatego będziemy rozmawiać o bezpieczeństwie całego tego systemu.

Bezpieczne projektowanie takich systemów stało się trudne, tylko jak w 2025 roku zacząć je chronić? Najlepiej zacząć od jasnego spojrzenia i przedstawienia za pomocą jasnej mapy i wytycznych, jak takie bezpieczeństwo powinno wyglądać ze względu na to w jaki sposób zmienia się definicja bezpieczeństwa w oparciu o aplikacje i systemy AI. W 2023 roku Google, dzięki swojej wieloletniej współpracy ze specjalistami z różnych dziedzin – nie tylko bezpieczeństwa i AI, ale też osób zajmujących się moralnością, przechowywaniem danych czy spójnością z zewnętrznymi frameworkami bezpieczeństwa i zgodności – stworzyło Secure AI Framework.

Jest to framework dla osób, które chciałyby zaprojektować i wdrożyć swoją aplikację AI. To jest bardzo ważne: jest to framework przeznaczony do projektowania systemów. Początkowo został stworzony dla celów wewnętrznych Google, a dopiero potem udostępniony jako darmowy framework dla każdego.

Napiszcie mi na czacie, czy macie już jakieś systemy oparte o AI, czy macie już jakieś doświadczenie? Będzie mi bardzo miło zobaczyć, jak to z waszej strony wygląda, bo inaczej rozmawia się z ludźmi, którzy już nad tym pracują, a inaczej z osobami, które dopiero planują wdrożenia.

Widzę odpowiedzi: brak doświadczenia, rozpoznajemy bojem, testy na produkcji też są.

No to ten framework będzie idealny dla osób, które jeszcze nie zaczęły swojej przygody, dlatego że ustandaryzuje podejście do pracy nad systemami AI. Bezpieczeństwo w tych systemach jest skomplikowane – ciężko jest w komunikacji między poszczególnymi osobami w zespole i elementami infrastruktury zrozumieć wzajemne zależności. Musimy najpierw dać możliwość rozmowy między zespołami, żeby zrozumieć, jak to dobrze zabezpieczyć.

 

Filary bezpieczeństwa SAIF

Secure AI Framework jest zaprojektowany na podstawie dotychczasowych rozwiązań, ale warto do niego co jakiś czas wracać, ponieważ będzie aktualizowany za każdym razem, gdy powstaną nowe metody obrony i ataku. Dlatego Secure AI framework powinno być czymś, co mamy jak taką fiszkę z informacjami jak do tego naszego bezpieczeństwa AI podchodzić, dlatego jeśli ktoś chciałby po tym webinarze albo po przeczytaniu samego frameworka uzna że wszystko wie, to nie tędy droga. Żeby dobrze zrozumieć w jaki sposób korzystać z frameworka, trzeba go wdrażać w życia i mieć go na każdym etapie projektowania. Jako jeden z pionierów technologii, zespół Google opracował zespół reguł i praktyk mających na celu zwiększenie efektywności bezpieczeństwa. 

Czyli tym jest właśnie ten Secure AI Framework – zespół reguł, informacji, które będa potrzebne podczas przeglądania i alizowania tego w jaki sposób nasza aplikacja ma wyglądać. Umożliwia to identyfikowanie poszczególnych zagrożeń, takich jak prompt injection, kradzież modelu, data poisoning. Może to być też kradzież danych treningowych, czyli przechodzimy do tego, od czego to nasze AI się wywodzi – danych.

Zmienia on również postulat dotyczący tego, co jest najważniejsze w aplikacji. Zwykle jest tak, że podchodzimy do aplikacji AI jako takiej zwykłej, a przeważnie w aplikacjach AI dane są naszym kodem – to z nich i z modelu wynika, w jaki sposób system będzie działał. Możemy mieć najlepszy możliwy kod napisany w Go czy Pythonie, ale jeśli wprowadzone dane będą nieprawidłowe, zatrute lub śmieciowe, nasza aplikacja będzie zupełnie bezużyteczna.

Stworzenie własnego frameworka przez małą firmę czy startup jest niezwykle trudne ze względu na brak wieloletniego doświadczenia, które posiada Google, na przykład z Bardem czy nawet na samym początku filtrów na Gmailu, które miały wykrywać spam. To całe to doświadczenie zawiera SAIF.

Przejdźmy dalej, Safe AI Framework wspiera osoby, które są zaangażowane w proces tworzenia takiego systemu na wszystkich poziomach, czyli od najbardziej podstawowego poziomu pracowników, inżynierów i deweloperów, którzy model mają stworzyć, wsparcia kadry kierowniczej, którzy mają koordynować pracę wszystkich zespołów, no i zarządu żeby lepiej mogli zrozumieć w jaki sposób ta praca się odbywa i jak można wdrożyć kontrole i audyty podczas pracy.

3,5 sekundy to średni czas trwania reakcji zespołu bezpieczeństwa Google na incydenty związane z AI. Możemy to zobaczyć na przykładzie testów Gemini połączonego z wyszukiwarką Google – kiedy zaczęła przekazywać informacje, które nie podobały się użytkownikom i powodowały głośne nagłówki, zostało to od razu zmienione i wyłączone z użytkowania. Ważne jest to, żeby każdy taki system AI miał możliwość wsparcia, aby na każdym etapie decyzyjności można było te zmiany i hotfixy wprowadzać.

Wiele organizacji nie posiada w swoich szeregach kadr specjalistów do spraw bezpieczeństwa, inżynierów chmurowych, programistów, zespołów do zarządzania ryzykiem, przetwarzaniem danych czy zgodnością z prawem. Dlatego korzystanie z SAIF ma duże znaczenie dla wszystkich. Jak spojrzymy sobie tutaj na ten opis, mamy poszczególne elementy SAIF-a, które pomogą w każdym z tych zespołów. Czy znaczy, że skoro SAIF jest dla każdego, to jest do niczego? Otóż nie, bo specjalizuje się w tym, żeby pomóc zrozumieć i stworzyć dobrą kooperację między wszystkimi elementami podczas produkcji systemu – nie tylko na elementach czysto informatycznych, ale też na tym ludzkim elemencie. 

Bardzo często największym problemem podczas tworzenia aplikacji z wykorzystaniem AI jest „Carbon Base Unit”, czyli osoby i elementy oparte o węgiel – po prostu ludzie. Najczęściej to ludzie są powodami problemów, bo komputery same w sobie nie dają się oszukać, a jeżeli my damy się oszukać, nasz system też będzie dziurawy.

Mamy sześć kluczowych filarów bezpieczeństwa SAIF, na których cały framework się opiera:

1. Osadzenie ryzyka dotyczącego systemów AI dla procesów biznesowych. Są to wszelkie ryzyka związane z systemami AI, a dokładnie to, w jaki sposób zmienia się nasz pogląd na bezpieczeństwo i założenia aplikacji w związku z zastosowaniem modelu. Ma to szczególne znaczenie dla ekspertów bezpieczeństwa, ponieważ muszą zmienić sposób patrzenia na zabezpieczenia, podchodząc do nich całościowo. Nie można tego rozbić na poszczególne elementy: wdrożeniowe, infrastrukturalne, danych, komunikacji API czy komunikacji z użytkownikiem. Trzeba za każdym razem traktować to jako całość.

Najlepiej jest to pokazane na liście OWASP Top 10, nie wiem czy jestem w stanie Wam to pokazać, ale spróbuję. Czy kojarzycie w ogóle listę OWASP Top 10? Napiszcie czy ktoś kojarzy. Tak, no to dla Waszej informacji istnieje też  dla dużych modeli językowych. Warto na nią spojrzeć, by zobaczyć szerokie spektrum zagrożeń występujących przy korzystaniu z aplikacji AI. Są tu zagrożenia specyficzne dla AI, ale też ogólne dla aplikacji, zmienione przez sposób, w jaki AI jest projektowane i działa. Oprócz listy zagrożeń OWASP posiada również zestaw rekomendacji. Ten dokument jest publicznie dostępny w Google, wystarczy go wpisać i dostajemy listę najbardziej znanych podatności.

Kiedy osadzamy takie ryzyko, przede wszystkim robimy w głowie kalkulację: ile nasza aplikacja jest warta, ile dane w tej aplikacji są warte, jak te elementy ze sobą współgrają i jak wprowadzić poziom bezpieczeństwa, który będzie dla nas opłacalny. Oczywiście można byłoby aplikację z AI trzymać całkowicie odciętą od Internetu, ale wtedy będzie bezużyteczna. Dlatego warto spojrzeć na to wysokopoziomowo i powiedzieć sobie, na jaki poziom ryzyka możemy sobie pozwolić i jakimi funduszami dysponujemy. Czasami nie warto budować ceglanego muru i chować wszystkiego do sejfu, jeżeli naszą jedyną wartością jest przepis na rosół. Są dane ważniejsze i można przekierować fundusze w inne miejsce organizacji. Dlatego właśnie osadzenie tego ryzyka w naszych procesach biznesowych gdzie wykorzystujemy AI na przykład jeśli AI będzie wykorzystywane przez nasz system księgowy to może się okazać, że to będzie bardzo ważne dla naszych pracowników, żeby otrzymywało odpowiednie informacje np. na temat zarobków. Oczywiście takich przykładów może być bardzo dużo, SAIF nie jest w stanie przewidzieć w jaki sposób będzie wykorzystywana Wasza aplikacja, tylko pomaga Wam dojść do tego w jaki sposób możemy takie ryzyko dopasować do naszego projektu.

1. Dostosowanie ustawień dla środków ograniczających. Posiadając osadzone ryzyko, chcemy ograniczyć dostęp. Jeżeli mamy jakikolwiek element infrastruktury, do którego dostęp ma człowiek – dostęp do bazy danych treningowych czy interakcja z modelem przez aplikację – to takie miejsce musimy zidentyfikować i odpowiednio zabezpieczać. Nie chcemy, aby w naszym modelu zostały luki, o których nie wiemy lub nad którymi nie mamy kontroli. Tak jak wchodząc do domu wiemy, jakie drzwi i okna gdzie się znajduje i co może przez nie przejść, tak samo do każdego elementu AI powinniśmy mieć zapisane „drzwi” z odpowiednim zestawem kluczy i haseł oraz określeniem niebezpieczeństw. Dodatkowo wdrożone muszą być mechanizmy zabezpieczające na wypadek, gdyby ktoś jednak te drzwi przekroczył i wyniósł sofę z mieszkania – jak szybko jesteśmy w stanie to zauważyć?

Prawidłowa implementacja tych mechanizmów jest kluczowa. Obok standardowych mechanizmów ze zwykłych aplikacji, musimy pamiętać o specyfice AI – o wpływie danych treningowych na modelowanie, tuning i trenowanie. Przykładowo, tworzymy automatyczne zabezpieczenia, kiedy widzimy, że model daje odpowiedzi, których nie chcemy – np. LLM przekazujący informacje zawierające dane osobowe.

1. Rozszerzenie wykrywania i reagowania. Jeżeli ktoś wyniesie nam sofę, w jaki sposób to zauważymy? Czy będziemy mieć psa, który zaszczeka, czy alarm? W trakcie projektowania systemu AI cały system powinien być monitorowany przynajmniej raz na każdym poziomie: modelu, aplikacji, danych i infrastruktury. Jeśli ktoś próbuje dostać się do bazy danych lub kodu, musimy zostać poinformowani. Jeżeli ktoś próbuje dostać się do aplikacji serwującej odpowiedzi z modelu, też musimy wiedzieć, co jest normalnym ruchem, co anomalią, a co próbą ataku prompt injection.
2. Automatyzacja systemów obrony. Filar ten dotyczy automatyzacji naszej odpowiedzi na naruszenie. W jaki sposób będziemy przeciwdziałać, gdy sofa wyszła z mieszkania na podwórko? Jak wyizolować intruza lub wyłączyć dostęp z konkretnej puli adresów IP przy ataku DDoS? Dobrym przykładem jest współpraca systemów w Google Cloud gdzie możemy wykorzystać informacje które pochodzą z Vertex AI do takiego miejsca jak Security Command Center albo na przykład Cloud Armor. Security Command Center pomaga ze zwalczaniem data poisoning, a Cloud Armor chroni przed DDoS. Oba narzędzia są potężne i o nich samych można byłoby zrobić kolejne 2-3 webinary. Taką ciekawą rzeczą, którym mógłbym powiedzieć o Cloud Armor, który też wykorzystuje sam w sobie wykorzystuje do ochrony, żeby wykrywać schematy naszego ruchu, też może być AI do ochrony naszego AI. Czyli AI nie musi być elementem ochrony ale samym elementem chronionym.
3. Harmonizacja ustawień na poziomie platformy. Cały system należy traktować jako jedną całość i utrzymywać równe standardy na każdym z jego elementów. Jeżeli jesteśmy w stanie zabezpieczyć coś jednym sposobem i mieć jeden system alertowania dla całego systemu AI, zróbmy tak. Nie chcemy, aby każdy z elementów miał inny sposób alertowania i obrony. 

 

Hakerzy i szkodliwe organizacje również korzystają z AI i mogą wykorzystać nasz system, jeśli źle go zabezpieczymy. Możemy wykorzystać nasze AI, aby potrafiło się chronić, wykrywało wektory ataków i im zapobiegało. Czyli jeżeli hakerzy wykorzystują najnowsze trendy i technologie, to my też powinniśmy. Oprócz tego czym są te filary SAIF, ważne jest, by być na bieżąco z informacjami, jakie są najnowsze trendy.

 

Mapa ryzyka i zabezpieczeń AI

Przechodzimy do sedna frameworku, czyli mapy i zabezpieczeń. Mapa składa się z czterech stref: danych, infrastruktury, modelu i aplikacji. Pomaga zidentyfikować potencjalne zagrożenia, ryzyka oraz wskazuje miejsca, w których możemy wprowadzić środki łagodzące.

W pracy ze specjalistami często dochodzi do nieporozumień. Ja jestem specjalistą od bezpieczeństwa, ale nie od AI per se, i ciężko mi czasami zrozumieć inżyniera AI projektującego system. Taka mapa, na którą spojrzymy razem i na której inżynier wskaże: „tutaj jest problem, tutaj potrzebuję pomocy”, pozwala mi lepiej zareagować. Dlatego mapa powinna być wzorcem dla każdego systemu bezpieczeństwa i każdego systemu AI. Większość tych systemów będzie wyglądała podobnie – jeśli chodzi o założenia dotyczące treningu, danych wejściowych czy filtracji będą wspólne. Usystematyzowanie tej wiedzy w zespole to główne zadanie mapy.

Oprócz samej tej mamy mamy też opis dla każdej ze stref. Framework SAIF bazuje na tym, że każdy element, który będzie ukazany, był stosunkowo dobrze wyjaśniony. Oczywiście to jest wyjaśnienie wysokopoziomowe, nie mamy tutaj dokładnego przykładu jak to ma wyglądać u nas, tylko ma pokazać w jaki sposób mamy do tego podchodzić.

Tak jak tutaj mamy strefę infrastrukturalną:

• to czym jest infrastruktura, czyli ktoś by powiedział maszyny wirtualne, no niekoniecznie, to może być cala platforma chmurowa, kod, framework modelu, sposób przeprowadzania tuningu, ewaluacji i treningu oraz praktyczne elementy wdrożenia.
• Strefa danych: Tworzenie modeli bazuje na dynamicznych systemach danych. Mamy zestaw danych pierwotnych, przefiltrowany, przemodelowany i używany jako baza do odpowiedzi, która stale się zmienia. Wyciek może nastąpić na każdym z tych poziomów. Nie chcemy stracić modelu przez kradzież czy inżynierię wsteczną, ani stracić wartościowych danych treningowych zawierających poufne informacje.
• Strefa modelu: Warstwa leżąca bliżej człowieka, stanowiąca „mózg”, z którym interakcję prowadzi API lub użytkownik. Największą trudnością jest brak możliwości łatwego prześledzenia wstecznego, jak model wygenerował konkretną odpowiedź. Połączenie kodu i wag musi dawać wgląd w przetwarzanie danych i możliwość wpływu na model podczas uczenia (np. poprzez ograniczenie danych, listy wykluczające czy nagradzanie wyników). Model nigdy nie powinien być traktowany jako produkt skończony – zawsze może zostać nauczony na większej ilości lub lepszej jakości danych.
• Strefa aplikacji: Element mający bezpośrednią styczność ze światem zewnętrznym i Internetem. Aplikacja może być skanowana, a atakujący mogą próbować ją przejąć, by wykorzystać model do własnych celów. Aplikacją nie musi być tylko agent – może to być inny model AI, w którym nasz model stanowi jedynie część (np. weryfikującą odpowiedzi), albo funkcja większego systemu wsparcia decyzyjnego. Użytkownikiem aplikacji również nie musi być człowiek, lecz inny komputer.

 

Analiza zagrożeń na przykładzie Data Poisoning

Każda strefa posiada swoje własne ryzyka i zabezpieczenia. Przechodząc przez mapę od danych zewnętrznych po użytkownika na samej górze, widzimy zagrożenia oznaczone jako wdrożone, zauważone i złagodzone. Za każdym razem widoczne są dokładne informacje, w którym miejscu możemy wprowadzić zabezpieczenia.

Fragment na żywo prezentujący mapę zagrożeń obejrzysz na nagraniu (czas 33:34)

Teraz powinno być widać, to jesteśmy na mapie. Możemy rozpocząć taką wspólną przygodę. Nie wiem czy ktoś z Was sam próbował przejść przez tę mapę i zrozumieć w jaki sposób ma ona nam pomóc. Najlepiej jest przeklikać też to samemu, dlatego że bardzo często będziemy wybierać to, co nas dotyczy. Nie będziemy zajmować się każdym możliwym ryzykiem, tylko konkretne osoby będa zajmować się konkretnymi zagrożeniami i łagodzeniem.

Tutaj możemy przejrzeć sobie naszą aplikację z wykorzystaniem AI, czyli widzimy aplikacje, model, dane i infrastrukturę. Mamy tutaj cały ten poziom, o którym wcześniej mówiłem – od danych zewnętrznych, z których będziemy brać dane do samej góry, czyli użytkownika. Rozpoczynając naszą podróż po tej mapie zobaczymy kilka ważnych elementów:

• wdrożone, 
• zauważone, 
• złagodzone. 

Za każdym za każdym razem jak będziemy widzieć jakiekolwiek zagrożenie, na tej mapie zobaczymy dokładnie te informacje czyli, w którym miejscu możemy wprowadzić nasze zagrożenie, czyli w tym przypadku w data poisoning możemy już mieć na etapie naszych źródeł danych na poziomie filtrowania i procesowania na poziomie storage po przefiltrowaniu, danych na poziomie treningu ewaluacji i na poziomie wewnętrznego storage naszego modelu. Data poisoning to jest taki szczególny przykład zagrożenia, bo powoduje to, że dane które będą wykorzystywane przez model będą zmienione albo w taki sposób wdrożone, że będą bezużyteczne. Ponieważ co z tego że będziemy mieć najbardziej efektywny model, jeśli będzie bazował na danych, które zostały zatrute – na przykład będzie miał dane, które będą zaprzeczały temu, w jaki sposób ten model miał przekazywać informacje. Taki przykład, ostatnio bardzo popularną informacją było to, że AI sekwencjonowania białek i aminokwasów zaczęło tak szybko tworzyć te wszystkie wzory, że jesteśmy w stanie tworzyć wzory 1000 razy szybciej niż przez ostatnie 150 lat. Wprowadzenie fałszywych danych do takiego modelu sprawiłoby, że cała praca poszłaby na marne. 

Atak taki można przeprowadzić bez bezpośredniego dostępu do aplikacji czy modelu – wystarczy dostęp do samych danych wejściowych, pozyskany np. poprzez inżynierię społeczną, ponieważ ludzie są jednym z najsłabszych elementów takich systemów i spreparować takie dane na swoje potrzeby. Finalnie może okazać się, że konkurencja, która sama chciała stworzyć taki model spowoduje, że takie AI będzie produkować bezużyteczne dane.

Zagrożenie to możemy łagodzić na poziomie treningu, ewaluacji i w samym modelu poprzez: wybór odpowiednich źródeł danych, szczegółowe filtrowanie przed przekazaniem ich do modelu, zabezpieczenie dostępu do storage’u oraz wykluczanie niepasujących danych na etapie ewaluacji za pomocą osobnych systemów. Podchodzimy do danych jak do kodu – nie chcemy niepotrzebnych lub szkodliwych danych w naszym modelu.

Przejdźmy może sobie przez listę. Widzimy, że mamy tutaj bardzo dużą liczbę zagrożeń, możemy sobie na przykład wyświetlić model exfiltration, prompt injection. Możemy przejść przez historię wielu zagrożeń i odwzorować sobie w jaki sposób ma to wyglądać. Czy uważacie taką mapę za przydatną? Bo moim zdaniem jako osoby, która nie znała się na AI, to dopiero od niedawna jestem w to zaangażowany i bardzo mi się to przydało.  

Google Cloud Platform jest oparte na SAIF bo też mamy tam elementy wykorzystujące sztuczną inteligencję, ale to nie narzędzie, ale framework. Za pomocą GCP możemy wprowadzić SAIF w życie i jak to wprowadzić – zaraz zobaczymy.

Tutaj mamy listę wszystkich ryzyk, które są związane z mapą SAIF. Do każdego takiego ryzyka możemy sprawdzić jak można je złagodzić i kiedy mogą wystąpić oraz sprawdzić realne przykłady. Tak jak tutaj, mamy link, który mogę Wam nawet wysłać. Jedna z najbardziej potrzebnych informacji kiedy przechodzimy przez mapę SAIF, żeby nie tylko zobaczyć jak są przedstawione ryzyka i jak je interpretować, ale też zobaczyć jak te zagrożenia mogą wpływać na systemy. Tutaj na przykład mamy informacje o Spotify, które zaczęło wykrywać ogromne ilości piosenek AI, które zaczynały zaśmiecać playlisty. 

SAIF oferuje  też zakładkę kontroli. Daje ona kompletną listę środków zaradczych przypisanych do infrastruktury, modelu, aplikacji i danych. Każda kontrola zawiera opis działania, sposób wykorzystania, wskazanie roli w zespole odpowiedzialnej za implementację oraz mapowanie na konkretne ryzyka.

 

Korzyści z wdrożenia SAIF

Największą korzyścią z wdrożenia SAIF jest gotowość na to jak zmienia się nasz świat, zmieniające się regulacje europejskie, SAIF po pierwsze jest przydatne, a po drugie niedługo prawdopodobnie będzie to wymagane. Dlatego, że suweren nie śpi, suweren chce żeby wszystko było najbardziej zabezpieczone i przejrzyste żeby zwiększyć transparentność. My jako twórcy chcielibyśmy też ją zwiększyć i być rozliczani z tego w jaki sposób nasze AI jest stworzone i czy zgodnie z tym, jak suweren sobie zażyczył.

Mamy też gotowość na NIS2, to kolejny krok Unii Europejskiej w stronę zwiększenia bezpieczeństwa systemów kluczowych. Tworząc rozwiązania AI dla bankowości czy sektora zdrowotnego, istnieje duże prawdopodobieństwo, że aplikacja będzie podlegała NIS2. Niespełnienie wymagań i wyciek danych może skutkować karami sięgającymi do 2% rocznego obrotu firmy. Warto zabezpieczyć się od samego początku i tworzyć aplikacje zgodnie z wytycznymi. Te dokumenty są stopniowo wdrażane w Polsce czy innych krajach, dlatego warto się zabezpieczyć i już od początku mieć gwarancję, że będziemy tworzyć nasze aplikacje zgodnie z wytycznymi takich gigantów jak Google.

W kwestii bezpieczeństwa – AI w medycynie potrafi diagnozować niektóre choroby szybciej niż lekarze. Zatrute AI na etapie projektowania mogłoby stawiać błędne diagnozy, co zagrażałoby życiu ludzi. W przypadku modeli LLM nie chcemy sytuacji, w których model generuje niebezpieczne treści (np. podając przepisy na niebezpieczne substancje czy koktajle Mołotowa, co miało miejsce we wczesnych wersjach powszechnych modeli).

Kolejnym elementem frameworku jest AI Development Primer. To dokument zawierający szczegółowy opis interakcji między komponentami oraz wytyczne, jak interpretować zagrożenia, prowadzić notatki i współpracować między działami. Każdy inżynier i manager powinien go znać, aby posługiwać się wspólnym językiem.

Ostatnim narzędziem jest Self-Risk Assessment (samoocena ryzyka). Robił ktoś z Was już taki Self-Risk Assessment? Wyśle Wam link i każdy będzie mógł go przejśc.

Narzędzie przeprowadza użytkownika przez cykl pytań dotyczących roli (kreator/konsument modelu) oraz konkretnych zabezpieczeń (np. „Czy dysponujesz systemem zarządzania wszystkimi danymi szkoleniowymi?”). Na podstawie odpowiedzi generowany jest raport z ryzykami (np. ryzyko data poisoning przy braku kontroli storage’u) wraz z odnośnikami do odpowiednich sekcji frameworka, co pozwala wdrożyć poprawki i powtórzyć audyt.

Mamy jeszcze 7 minutek na pytania.

Magdalena Cuper: Gabriel, serdecznie dziękujemy za wartościową prezentację, także jeżeli są jakieś pytania to zachęcamy do zadawania ich. 

Gabriel Marchwant: Może jakieś takie faktyczne przykłady wdrożenia byście chcieli, w jaki sposób klienci albo my próbujemy rozwiązać różne kwestie.

 

Pytania i odpowiedzi

P: Jakie są praktyczne przykłady wdrożenia tego frameworka? 

Gabriel Marchwant: Głównym przykładem wykorzystania tego frameworka na podstawie naszych filarów jest ustalenie jednej konkretnej platformy pod nasze AI. W naszym przypadku jest to Google Cloud oraz Vertex AI. Korzystamy z jednego spójnego systemu, który umożliwia zarządzanie i tworzenie customowych alertów na poziomie konsoli Google Cloud oraz zarządzanie dostępem poprzez Google Workspace. Wszystko jest zharmonizowane i obsłużone przez jeden zespół. Kolejnym filarem jest monitorowanie za pomocą alertów konta billingowego, alertów Vertex AI, Security Command Center oraz VPC Service Controls w celu odizolowania zasobów projektu. Do tego dochodzi prawidłowe zarządzanie dostępem przez IAM.

P: Czy używany model AI ma znaczenie i jak SAIF ma się do innych frameworków, np. MITRE ATLAS?

Gabriel Marchwant: Ten framework nie służy do samego monitorowania czy bieżącego zarządzania ryzykiem w trakcie działania, ale do wdrożenia go na etapie projektowym (Secure by Design). Inne frameworki, jak MITRE ATLAS, są również przydatne i wzajemnie się nie wykluczają. Co do samego modelu – i tak, i nie. Niektóre modele posiadają swoje własne podatności czy charakterystykę, jednak SAIF stworzony jest uniwersalnie. Wybierając dany model, należy zaimplementować go w naszą mapę ryzyka, poznać jego specyfikę i odpowiednio udokumentować.

Magdalena Cuper: Bardzo dziękujemy za odpowiedzi. W razie pojawienia się kolejnych pytań, zapraszamy do kontaktu. Chcielibyśmy podziękować wszystkim uczestnikom za udział i zaangażowanie.

Cały webinar został nagrany i w ciągu czterech dni roboczych wyślemy link do nagrania. W wiadomości znajdą się również dane kontaktowe oraz wszystkie prezentowane dzisiaj linki. Zachęcamy do obserwowania naszych profili w mediach społecznościowych i udziału w kolejnych wydarzeniach. Życzymy owocnego wdrażania bezpiecznych rozwiązań AI.

Dziękujemy ślicznie, trzymajcie się!