Bezpieczeństwo sztucznej inteligencji wymaga solidnych zabezpieczeń architektonicznych. To jest prosta odpowiedź, i to właśnie ten element ludzie często próbują ominąć. Jeśli system AI może widzieć prywatne dane, wywoływać narzędzia lub uruchamiać akcje, sama jakość modelu nie wystarczy. System potrzebuje wokół siebie mocnych murów.
Zawsze wracam do jednego prostego punktu: model to tylko część ryzyka. Rzeczywisty obszar ataku to cały system wokół niego. Obejmuje to prompty, narzędzia, ścieżki danych, uprawnienia, dzienniki zdarzeń oraz kod, który je łączy. Jeśli którakolwiek z tych części będzie luźna, model można popchnąć do robienia czegoś, czego nie powinien robić.
Dlatego „zabezpieczanie promptu” to zbyt mały plan. Wstrzykiwanie promptów (prompt injection) jest realnym zagrożeniem, ale jest tylko jedną z dróg do złamania systemu AI. Złe wejście może ukryć się w stronach internetowych, dokumentach, e-mailach, a nawet w zwykłym tekście użytkownika. Jeśli system traktuje wszystko to jako zaufane, model może zostać oszukany i podążyć za wrogimi instrukcjami.
Lepszym podejściem jest perspektywa architektoniczna. Niezaufana treść powinna pozostawać niezaufana na każdym etapie działania systemu. Oznacza to wyraźne granice między tekstem użytkownika, regułami systemowymi a danymi zewnętrznymi. Oznacza też, że model nie powinien domyślnie mieć szerokiego dostępu do narzędzi. Jeśli może dotrzeć do wszystkiego, jeden błąd może szybko się rozprzestrzenić.
Tu liczy się zasada najmniejszych uprawnień. System powinien dawać każdej części tylko taki dostęp, jaki jest potrzebny do wykonywania jej zadań. Jeśli narzędzie może wysyłać wiadomości, nie powinno też czytać poufnych danych. Jeśli agent może pobierać dane, nie powinien być w stanie uruchamiać ryzykownych akcji bez osobnego sprawdzenia. Małe uprawnienia zmniejszają szkody, gdy coś pójdzie nie tak.
Chcę też narysować twardą linię między kontrolą a treścią. Język naturalny to nie kod, ale systemy AI często tę linię zamazują. To tam zaczynają się kłopoty. Bezpieczna projektowa utrzymuje politykę w logice aplikacji, a nie wewnątrz niejasnej instrukcji zakopanej w promptcie. Model może pomagać w interpretacji tekstu, ale ostateczne barierki ochronne powinny znajdować się poza modelem.
To jeden z powodów, dla których warstwowa obrona pojawia się w poważnych wytycznych. Jedna warstwa może przechwycić próbę wstrzyknięcia promptu. Inna może zablokować wywołanie narzędzia. Trzecia może zalogować zdarzenie i powiadomić człowieka. Żadna pojedyncza kontrola nie jest idealna. Bezpieczeństwo zawodzi, gdy ludzie za bardzo ufają jednej warstwie.
Izolacja to kolejna podstawowa bariera ochronna. Poczuciwe kroki powinny działać w osobnych usługach lub piaskownicach, gdy to możliwe. Dzięki temu, nawet jeśli jedna część zostanie oszukana, nie będzie mogła automatycznie dotrzeć do reszty. To nudna inżynieria, co zwykle jest dobrym znakiem. Nudne systemy są często bezpieczniejszymi systemami.
Myślę, że granice danych zasługują na większą uwagę niż im się przydziela. Systemy AI często mieszają zaufane instrukcje z niezaufanym tekstem od użytkowników lub źródeł zewnętrznych. To mieszanina jest niebezpieczna. System powinien oznaczać źródło danych i oddzielać te źródła od siebie. Jeśli tekst zewnętrzny trafi do promptu, nie powinien zyskać tego samego statusu co instrukcje systemowe.
Monitorowanie również ma znaczenie, ale nie jako magiczne rozwiązanie. Dzienniki zdarzeń, alerty i ścieżki audytu same w sobie nie zatrzymują ataku. Pomagają ludziom zauważyć dziwne zachowania, śledzić działania i reagować szybciej. W praktyce ma to znaczenie, ponieważ awarie AI często początkowo są ciche. System może wyglądać normalnie, dopóki nie przekroczy już jakiejś granicy.
Istnieje też słaby punkt w wielu systemach AI, który jest niedoceniany: używanie narzędzi. Gdy model może przeglądać sieci, pisać pliki, badać bazy danych lub wywoływać interfejsy API, przestaje być tylko generatorem tekstu. Staje się częścią systemu działań. Oznacza to, że każde wywołanie narzędzia wymaga walidacji, ograniczenia zakresu i często osobnego sprawdzenia przed wykonaniem czegokolwiek wrażliwego.
Chcę być szczery co do jednego ograniczenia. Żadna architektura nie czyni AI całkowicie bezpieczną. Metody ataków ciągle się zmieniają, a niektóre środki obronne działają lepiej w jednym rozwiązaniu niż w innym. Wstrzykiwanie promptów to wciąż aktywny obszar badawczy, a najlepsze kontrole są warstwowe, a nie ostateczne. Bezpieczeństwo tu to ruchomy cel, a nie rozwiązany problem.
Dlatego ufam architekturze bardziej niż obietnicom. Bezpieczny system AI nie zależy od tego, by model był mądry, spokojny czy posłuszny. Zależy od wąskich uprawnień, czystego rozdzielenia, silnej walidacji, monitorowania i bezpiecznych trybów awarii. Model może nadal być użyteczny. Po prostu nie powinien rządzić wszystkim.
To jest też praktyczna odpowiedź na pytanie o cyberbezpieczeństwo. Bezpieczeństwo AI to nie dodatkowa funkcja. Jest częścią projektowania systemu od początku i potrzebuje prawdziwych granic, a nie nadziei. To rodzaj uczciwej pracy, którą staram się mieć na uwadze, i dobrze wpisuje się w koncepcję The Model Log: jedna praktyczna koncepcja AI, jeden działający przykład i jeden szczery rzut oka na to, co naprawdę działa.
