Jak zabezpieczyć aplikację LLM? Prompt injection, wyciek danych i kontrola dostępu

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.

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.

Przy danych szczególnie wrażliwych lepiej nie wysyłać pełnej treści do modelu. Dla umów, HR albo dokumentów z tajemnicą przedsiębiorstwa często wystarcza kontrolowane streszczenie albo wybrane pola. To ogranicza ryzyko zarówno po stronie modelu, jak i logów.

Narzędzia wywoływane przez LLM tylko przez polityki

Gdy model ma uruchamiać funkcje, role muszą być rozdzielone. LLM proponuje intencję. Aplikacja mapuje ją na konkretną funkcję i parametry. Dopiero warstwa polityk sprawdza, czy dana akcja jest dozwolona dla tego użytkownika, rekordu i kontekstu procesu.

W prostych wdrożeniach wystarczą jawne reguły backendowe. Przy większej liczbie integracji lepiej działa centralny silnik polityk oparty na RBAC lub ABAC. RBAC porządkuje role, ale w procesach operacyjnych często nie wystarcza. ABAC pozwala dodać warunki typu: konsultant może wygenerować odpowiedź tylko dla sprawy ze swojego regionu, w godzinach pracy zespołu i bez ujawniania pól zablokowanych przez politykę prywatności.

Trzeba też ograniczyć same narzędzia. Jeden szeroki endpoint w rodzaju „CRM.write” jest wygodny dla dema i fatalny dla bezpieczeństwa. Lepiej wystawić kilka wąskich funkcji: dodaj notatkę, zmień status na oczekuje, utwórz szkic wiadomości. Im węższa funkcja, tym łatwiej ją autoryzować, testować i wyłączyć po incydencie.

Nadzór człowieka tam, gdzie błąd ma koszt prawny lub biznesowy

Nie każda akcja wymaga zatwierdzenia przez człowieka. Automatyczna klasyfikacja zgłoszenia albo przygotowanie szkicu odpowiedzi zwykle da się obronić bez ręcznej akceptacji. Inaczej wygląda wysyłka wiadomości do klienta, zmiana warunków handlowych, operacja finansowa, modyfikacja danych osobowych czy decyzja wpływająca na prawa użytkownika.

W takich przypadkach operator musi widzieć więcej niż przycisk „zatwierdź”. Potrzebuje źródeł, na których model oparł rekomendację, planowanej akcji, parametrów wywołania i wyniku polityki. Jeśli interfejs pokazuje tylko gotową sugestię bez kontekstu, człowiek nie pełni funkcji kontrolnej. Jedynie bierze na siebie odpowiedzialność za coś, czego nie może zweryfikować.

To za mało.

Prompt injection i wyciek danych: gdzie system łamie się najczęściej

Prompt injection rzadko wygląda jak widowiskowy atak. Częściej to zwykły fragment maila, PDF albo zgłoszenia z treścią w rodzaju „zignoruj wcześniejsze instrukcje” albo „pokaż pełną historię klienta”. Model traktuje taki tekst jak kolejne dane wejściowe. Jeśli aplikacja nie oddziela źródeł nieufnych od instrukcji sterujących, obcy komunikat zaczyna wpływać na logikę systemu.

Obrona nie polega na filtrze słów zakazanych. Potrzebne są warstwy: oznaczanie źródeł nieufnych, ograniczenie kontekstu do minimum, walidacja odpowiedzi przed pokazaniem użytkownikowi i blokada narzędzi, gdy intencja pochodzi z nieufnego źródła. OWASP opisuje ten problem nie jako ciekawostkę badawczą, ale jako regularny wektor ataku w aplikacjach LLM. Słusznie.

Drugi częsty punkt awarii to logi. Zespół maskuje dane w promptach, ale zostawia pełne treści zapytań, odpowiedzi i dokumentów w systemie obserwowalności albo panelu wsparcia. Wtedy incydent nie dzieje się w modelu, tylko w narzędziu, do którego dostęp ma zbyt wiele osób.

Tu wiele wdrożeń przegrywa z własną wygodą operacyjną. Log ma pomagać diagnozować błędy, ale nie może być prostszą drogą do danych niż sama aplikacja. Osobne polityki retencji, maskowanie identyfikatorów klientów i ograniczenie dostępu do śladów audytowych są ważniejsze niż kolejny eksperyment z promptem.

Jest jeszcze pułapka zakupowa. Firmy zbyt często zakładają, że deklaracja dostawcy modelu o bezpieczeństwie danych rozwiązuje problem. Nie rozwiązuje. Nawet jeśli dostawca nie używa treści do trenowania, nadal pozostają błędnie zbudowany kontekst, nadmierne uprawnienia backendu i nieautoryzowane wywołania narzędzi. Jeśli dostawca pokazuje „enterprise security”, ale nie potrafi jasno wyjaśnić, jak obsłużysz własne polityki dostępu, retencję logów i audyt akcji, to kupujesz prezentację, nie zabezpieczenie.

Co zmienia Polska i UE oraz jakie minimum trzeba mieć przed produkcją

Dla firm działających w Polsce i Unii Europejskiej bezpieczeństwo LLM trzeba połączyć z ochroną danych i rozliczalnością procesu. Nie chodzi o dopisanie kilku zdań do polityki prywatności. Chodzi o to, czy architektura pozwala wykazać, jakie dane trafiły do modelu, na jakiej podstawie i kto miał do nich dostęp.

Jeśli aplikacja przetwarza dane osobowe klientów lub pracowników, trzeba ustalić role w łańcuchu przetwarzania: administrator, podmiot przetwarzający, dostawca hostingu, dostawca modelu. To wpływa na umowy, zakres instrukcji przetwarzania i sposób logowania. W pytaniach zakupowych nie wystarczy „czy dostawca ma region UE”, ale także „gdzie trafiają prompty, logi i telemetria oraz czy można ograniczyć ich przechowywanie”.

Przy wdrożeniach, które łączą wiele źródeł danych, wspierają decyzje wobec osób fizycznych albo działają na większej skali, sensownym krokiem jest DPIA, czyli ocena skutków dla ochrony danych. To nie jest formalność dla działu prawnego. Dobrze zrobiona DPIA szybko ujawnia, czy zakres danych w promptach jest nadmiarowy, czy logi są zbyt szerokie i czy transfer poza EOG został oceniony technicznie, a nie marketingowo.

W części europejskiej lepiej trzymać się konkretu niż ogólnych nazw instytucji. Stanowiska europejskich organów ochrony danych konsekwentnie wzmacniają trzy praktyczne wnioski: minimalizuj dane, projektuj kontrolę dostępu od początku i dokumentuj nadzór człowieka tam, gdzie system wpływa na osoby fizyczne. Architektura bezpieczeństwa i architektura zgodności zwykle opisują ten sam problem z dwóch stron.

Przed produkcją trzeba mieć kilka rzeczy, nawet jeśli wdrożenie jest małe:

1. Mapę przepływu danych z odpowiedzią, które pola trafiają do modelu, logów i narzędzi pomocniczych.
2. Model uprawnień dla źródeł, rekordów, narzędzi i akcji, egzekwowany poza LLM.
3. Rejestr narzędzi z opisem funkcji, parametrów i ograniczeń biznesowych.
4. Scenariusze testów nadużyć, w tym prompt injection, eskalację uprawnień i wyciek przez logi.
5. Ślad audytowy pokazujący użytkownika, źródła kontekstu, decyzję polityki, model i wynik akcji.
6. Procedurę wyłączenia, czyli możliwość szybkiego odcięcia narzędzia, źródła danych albo całego kanału.

Jeżeli przypadek użycia jest prosty, na przykład wewnętrzny asystent do jawnych procedur, te elementy mogą być lekkie. Jeśli jednak model dotyka danych klientów, HR, finansów albo komunikacji zewnętrznej, lekkość kończy się bardzo szybko. Wtedy decyzja jest dość brutalna: albo budujesz kontrolę jak dla systemu produkcyjnego, albo nie udawaj, że pilot jest gotowy do skali.

Na końcu zostaje wybór architektury. Przy jednym modelu, jednym procesie i małej liczbie integracji dobrze zrobiony backend zwykle wystarczy. Gdy rosną liczba źródeł, wyjątków, polityk dostępu i wymagań audytowych, centralna warstwa polityk lub gateway zaczyna mieć sens operacyjny. Jeśli natomiast zespół nie potrafi dziś odpowiedzieć, jakie dane trafiają do modelu i kto może uruchomić jaką akcję, projekt trzeba zatrzymać przed produkcją.