Bezpieczeństwo AI opiera się na solidnej architekturze. To jest prosta odpowiedź, a to właśnie ten element ludzie często pomijają. Model ma znaczenie, ale system wokół niego ma takie samo znaczenie.
Wciąż wracam do prostego faktu: większość awarii AI nie wynika wyłącznie z błędów modelu. Są to awarie systemu. Model widzi dane wejściowe, ale aplikacja decyduje, jakie dane wejściowe do niego trafiają. Aplikacja również decyduje, do jakich danych może mieć dostęp, jakie narzędzia może wywołać i co wychodzi z systemu. Jeśli te warstwy są słabe, model ponosi winę za problem projektowy.
Dlatego też barierki ochronne (guardrails) stanowią centrum prawdziwego bezpieczeństwa AI. Bariatki ochronne to mechanizmy kontrolne, które kształtują zachowanie jeszcze przed tym, jak odpowiedź dotrze do użytkownika. Mogą filtrować dane wejściowe, sprawdzać wyjścia i ograniczać działania w czasie wykonania. W prostych słowach, są to kontrole, które utrzymują system w jego granicach. Nie jest to miły dodatek. To jest architektura.
Kluczową częścią jest separacja. Bezpieczny system AI nie pozwala modelowi robić wszystkiego naraz. Oddziela obsługę promptów, dostęp do danych i wykonywanie akcji na różnych warstwach. Daje to systemowi miejsca do inspekcji, blokowania i logowania aktywności. Ułatwia też zmianę projektu bez przepisania całej aplikacji przy każdej zmianie polityki.
Uważam, że ten szczegół ma większe znaczenie niż większość ludzi przyznaje. Jeśli zasady bezpieczeństwa żyją w jednym dużym prompcie, są kruche. Tekst prompta może zostać zignorowany, zmieniony lub oszukany. Jeśli zasady bezpieczeństwa żyją w pośrednim oprogramowaniu (middleware), kontrolach dostępu i sprawdzaniu polityk, trudniej je ominąć. To lepszy kształt dla bezpieczeństwa.
Ten sam pomysł pojawia się w typowych ścieżkach ataku. Iniekcja prompta jest jednym z najjaśniejszych przykładów. Wrogie dane wejściowe mogą próbować odciągnąć model od jego zadania. Jeśli model ma również szeroki dostęp do narzędzi, szkoda może rozprzestrzenić się poza złe teksty. Może dotrzeć do danych, API lub wewnętrznych akcji. Dlatego architektura musi traktować model jako jeden komponent, a nie jako całą granicę bezpieczeństwa.
To tutaj liczy się zasada najmniejszych uprawnień. Agent AI powinien otrzymywać tylko taki dostęp, jaki jest potrzebny do bieżącego zadania. Jeśli nie potrzebuje dostępu do zapisu, nie powinien go mieć. Jeśli nie potrzebuje narzędzia, nie powinno mu ono być widoczne. Proste zasady tego rodzaju wciąż wykonują większość pracy. Bezpieczeństwo zawodzi szybko, gdy agent może uzyskać dostęp do zbyt wielu rzeczy.
Zwracam też uwagę na to, gdzie mieści się ludzka recenzja. W przypadku działań o wysokim ryzyku krok wymagający zgody człowieka nadal jest użyteczny. Spowalnia proces, tak. O to chodzi. Szybkość nie jest jedynym celem. W systemach AI dodatkowa kontrola przed wrażliwą akcją może powstrzymać wyglądającą na czystą pomyłkę przed zamianą jej w rzeczywisty problem.
Logowanie jest częścią tego samego obrazu. Jeśli system nie może pokazać, co model zobaczył, co zwrócił i co próbował zrobić, praca nad bezpieczeństwem staje się strzelaniem na oślep. Logi nie zapobiegają każdemu problemowi, ale czynią złe zachowania widocznymi. Widzialność jest często pierwszym krokiem ku kontroli.
Jest tu jedna uczciwa granica. Solidna architektura obniża ryzyko, ale nie sprawia, że system AI jest bezpieczny sam w sobie. Zagrożenie zmienia się wraz ze zmianą modeli, narzędzi i metod ataku. Niektóre metody barierek ochronnych wciąż ewoluują, a niektóre mechanizmy kontrolne działają lepiej w jednej formie produktu niż w innej. Projekt, który wygląda solidnie na papierze, może nadal zawieść pod presją chaotycznego, rzeczywistego użytku.
Dlatego ufam bardziej projektowi wielowarstwowemu niż pojedynczym poprawkom. Kontrole wejścia pomagają. Kontrole wyjścia pomagają. Ograniczenia narzędzi pomagają. Monitorowanie pomaga. Żadne z nich nie wystarczy samo w sobie. Razem tworzą kształt bezpieczeństwa, którego potrzebują systemy AI.
Gdy więc czytam twierdzenie, że bezpieczeństwo AI opiera się na solidnej architekturze, nie widzę marketingu. Widzę prawdę systemową. Model to tylko jedna część łańcucha. Bezpieczeństwo pochodzi z tego, jak ten łańcuch jest zbudowany.
Oto rodzaj praktycznego punktu, który The Model Log stara się utrzymać na uwadze: jeden praktyczny koncept AI, jeden działający przykład i jeden szczery spojrzenie na to, co naprawdę działa.
