Zabezpieczenie aplikacji LLM zaczyna się nie od dopracowania promptu, ale od prostego pytania: czy model ma tylko odpowiadać, czy też czytać dane operacyjne i uruchamiać akcje. W większości firm bezpieczniejszy i zwyczajnie tańszy jest dobrze ograniczony asystent niż agent z prawem zapisu. Jeśli system dotyka CRM, ticketów, poczty albo danych osobowych, kontrola dostępu musi działać poza modelem.
Najwięcej problemów nie bierze się dziś z samego LLM, tylko z warstwy aplikacyjnej. Wspólny indeks wiedzy bez filtrowania uprawnień. Konto techniczne z dostępem do kilku systemów naraz. Logi, które przechowują więcej niż widzi użytkownik. W takim układzie prompt injection jest tylko jednym z objawów. Prawdziwy kłopot zaczyna się tam, gdzie architektura ufa modelowi bardziej niż backendowi.
OWASP w LLM Top 10 porządkuje podstawowe klasy ryzyka: wstrzyknięcia instrukcji, ujawnienie danych, nadmierne uprawnienia i niebezpieczne użycie narzędzi. Z kolei NIST AI RMF przypomina o rozliczalności: trzeba wiedzieć, skąd system wziął dane, kto zatwierdził działanie i jak odtworzyć incydent. W środowisku produkcyjnym to nie jest dodatek na później. To warunek startu.
Jedna teza jest tu celowo ostra: większość firm nie potrzebuje dziś autonomicznego agenta w procesach z danymi klientów. Potrzebuje aplikacji LLM o wąskim zakresie, czytelnych uprawnieniach i przewidywalnym logowaniu. Agent wykonawczy ma sens dopiero wtedy, gdy organizacja naprawdę umie kontrolować dane, narzędzia i wyjątki procesowe. Rynek sprzedaje sprawczość modelu szybciej, niż firmy budują zdolność do jej nadzorowania.
Kiedy wystarczy backend, a kiedy potrzebna jest centralna warstwa polityk
Najprostszy podział ryzyka obejmuje trzy klasy wdrożeń. Nie po to, żeby produkować kolejną macierz, tylko żeby szybko ustalić, jak ciężka musi być warstwa bezpieczeństwa i czy projekt w ogóle nadaje się do produkcji.
Asystent informacyjny bez akcji
Model odpowiada na pytania, streszcza dokumenty, wyszukuje wiedzę i niczego nie zmienia w systemach. To najbezpieczniejszy wariant, ale tylko z pozoru prosty. Główne ryzyka to pobranie niewłaściwego kontekstu, ujawnienie treści z indeksu oraz wyciek przez logi i narzędzia obserwowalności.
W takim scenariuszu zwykle wystarcza dobrze zaprojektowany backend, jeśli spełnione są trzy warunki: jedno lub kilka spójnych źródeł, brak prawa zapisu oraz kontrola dostępu egzekwowana przed pobraniem kontekstu. Jeśli użytkownik nie ma prawa zobaczyć dokumentu w źródle, model nie może dostać jego fragmentu tylko dlatego, że pasuje semantycznie do pytania.
Asystent operacyjny z odczytem danych biznesowych
Tu zaczyna się realne tarcie. Model czyta CRM, zgłoszenia, historię zamówień, umowy albo notatki handlowe, ale sam niczego nie zapisuje. Na etapie pilota taki przypadek użycia wygląda niewinnie. Przy wdrożeniu między działami często przestaje.
Backend nadal może wystarczyć, ale tylko wtedy, gdy źródła mają zbliżony model uprawnień, zakres danych jest ograniczony, a zespół potrafi utrzymać maskowanie i retencję logów w jednym miejscu. Gdy każde źródło ma inne role, wyjątki per użytkownik i osobne zasady widoczności pól, centralna warstwa polityk albo AI Gateway dla wdrożenia AI przestaje być dodatkiem. Staje się sposobem na utrzymanie spójnej autoryzacji.
Dobry przykład to asystent dla obsługi klienta, który czyta tickety, zamówienia i notatki z CRM, aby przygotować odpowiedź dla konsultanta. Jeśli system zgłoszeń dziedziczy uprawnienia zespołowe, CRM ma wyjątki per opiekun klienta, a logi trafiają do wspólnego monitoringu, problemem nie jest jakość modelu. Problemem jest to, że jedna odpowiedź skleja dane z trzech systemów o różnych zasadach dostępu.
Agent wykonujący akcje
Najwyższe ryzyko pojawia się wtedy, gdy model może wysłać wiadomość, zmienić status sprawy, dopisać notatkę do CRM, uruchomić workflow albo pobrać dane z kolejnego systemu. W tym wariancie nie wystarczy instrukcja systemowa ani obietnica, że operator później spojrzy.
Jeżeli agent ma wpływ na dane klientów, komunikację zewnętrzną, finanse, HR albo uprawnienia użytkowników, potrzebna jest osobna warstwa decyzji: kto żąda akcji, na jakim rekordzie, z jakiego kanału i z jakim skutkiem biznesowym. Bez tego model staje się pośrednim administratorem systemów. To zły pomysł nawet wtedy, gdy demo wygląda świetnie.
| Scenariusz | Kiedy wystarczy backend | Kiedy potrzebna centralna warstwa polityk | Kiedy zatrzymać projekt |
| Asystent do dokumentów | Jedno źródło, spójne ACL, brak zapisu | Wiele repozytoriów, różne role, wspólne logi i maskowanie | Gdy indeks nie odwzorowuje uprawnień źródłowych |
| Asystent do CRM i ticketów | Odczyt kilku pól, jeden proces, mało wyjątków | Różne systemy, wyjątki per użytkownik, dane osobowe | Gdy backend działa na szerokim koncie technicznym |
| Agent wykonujący akcje | Tylko dla niskiego ryzyka i bardzo wąskich funkcji | Prawie zawsze, jeśli są narzędzia i wiele integracji | Gdy brak polityk, audytu lub zatwierdzania operacji wysokiego ryzyka |
Najgorszy wariant to półśrodek: agent z szerokimi uprawnieniami, bez silnika polityk, bez odtwarzalnego śladu audytowego i z planem, że bezpieczeństwo zostanie dopięte po pilocie. W aplikacjach LLM taki dług techniczny szybko wychodzi na danych klientów, nie w laboratorium.
Jak wygląda bezpieczna architektura aplikacji LLM w praktyce
W produkcyjnym wdrożeniu trzeba rozdzielić trzy rzeczy: dostęp do danych, wywołanie narzędzi i logowanie. Gdy te warstwy mieszają się w jednym promptcie albo w jednym koncie serwisowym, kontrola staje się iluzją.
RAG z kontrolą dostępu przed pobraniem kontekstu
Najczęstszy błąd w systemach RAG polega na budowie wspólnego indeksu wiedzy dla wszystkich użytkowników i próbie naprawienia tego dopiero na etapie odpowiedzi. To nie działa. Kontrola dostępu musi zadziałać przed pobraniem fragmentów do kontekstu.
Bezpieczny przepływ jest prosty. Użytkownik uwierzytelnia się w aplikacji. Warstwa autoryzacji wylicza jego uprawnienia do dokumentów, folderów, rekordów albo tagów klasyfikacyjnych. Retriever pobiera tylko te fragmenty, które mieszczą się w tym zakresie. Dopiero potem model dostaje zawężony kontekst.
Jeśli źródłem jest SharePoint, Confluence albo repozytorium plików, do indeksu trzeba przenieść metadane bezpieczeństwa: właściciela, dział, poziom poufności, grupy dostępu i datę ważności dokumentu. Sam embedding nie niesie informacji o tym, kto może zobaczyć treść. Bez metadanych filtrujących indeks staje się wygodnym skrótem do obejścia uprawnień źródłowych.
