Duże modele językowe (LLM) stały się integralnym elementem infrastruktury technologicznej przedsiębiorstw — od automatyzacji obsługi klienta, przez generowanie kodu, po analizę dokumentacji prawnej. Jednak wraz z rosnącą adopcją rośnie również powierzchnia ataku, a tradycyjne frameworki zarządzania ryzykiem IT nie uwzględniają specyficznych zagrożeń związanych z AI. Ten artykuł przedstawia kompletny framework oceny ryzyka LLM, zaprojektowany z myślą o potrzebach CISO, architektów bezpieczeństwa i zespołów compliance w organizacjach enterprise.
Dlaczego przedsiębiorstwa potrzebują dedykowanego frameworku ryzyka LLM?
Wdrożenie modeli LLM w organizacji enterprise to nie to samo co zakup licencji na oprogramowanie. Modele językowe wprowadzają fundamentalnie nową kategorię ryzyka, której tradycyjne frameworki — ISO 27001, NIST CSF, CIS Controls — nie adresują w wystarczającym stopniu. Tradycyjne bezpieczeństwo IT operuje na zasadzie deterministycznej: dane wejściowe dają przewidywalne wyniki, podatności mają konkretne sygnatury, a zachowanie systemu można w pełni opisać specyfikacją. LLM-y łamią każdą z tych zasad.
Po pierwsze, modele językowe są niedeterministyczne — ten sam prompt może generować różne odpowiedzi w różnych warunkach. Po drugie, ich wewnętrzna logika jest nieprzejrzysta (black box) — nawet twórcy modelu nie mogą precyzyjnie wyjaśnić, dlaczego model wygenerował konkretną odpowiedź. Po trzecie, interakcja z modelem odbywa się w języku naturalnym, co oznacza, że tradycyjne narzędzia filtrowania (WAF, reguły regex, sygnatury IDS) nie potrafią odróżnić złośliwego inputu od normalnego zapytania.
Skala wdrożeń LLM w przedsiębiorstwach rośnie wykładniczo. Według badań Gartnera z 2025 roku, ponad 78% dużych organizacji planuje lub już wdrożyło systemy oparte na generatywnej AI. Jednocześnie 60% z nich nie posiada formalnej polityki bezpieczeństwa AI (ISACA, 2025). Ta luka między adopcją a zabezpieczeniami tworzy ogromne pole do eksploatacji — zarówno przez atakujących zewnętrznych, jak i przez ryzyko wewnętrzne (niezamierzony wyciek danych, niekontrolowane użycie shadow AI).
Dedykowany framework ryzyka LLM łączy perspektywę bezpieczeństwa technicznego (OWASP Top 10 for LLM), zarządzania ryzykiem organizacyjnym (ERM) i compliance regulacyjnego (EU AI Act, NIS2). Bez takiego zintegrowanego podejścia organizacje albo zabraniają AI całkowicie (tracąc przewagę konkurencyjną), albo wdrażają ją bez kontroli (narażając się na poważne incydenty).
📚 Przeczytaj kompletny przewodnik: AI Security: AI w cyberbezpieczeństwie - zagrożenia, obrona, przyszłość
Krajobraz zagrożeń LLM — OWASP Top 10 for LLM Applications
OWASP (Open Web Application Security Project) opublikował specjalistyczną listę OWASP Top 10 for LLM Applications, która stanowi punkt odniesienia dla oceny bezpieczeństwa aplikacji opartych na modelach językowych. Wersja 2025 rozszerza zakres o zagrożenia związane z agentycznymi systemami AI. Poniżej przedstawiamy przegląd najważniejszych kategorii zagrożeń w kontekście enterprise.
LLM01: Prompt Injection — najpoważniejsze zagrożenie. Atakujący manipuluje promptem (bezpośrednio lub pośrednio przez dane przetwarzane przez model), aby wymusić nieautoryzowane zachowanie. W kontekście enterprise, prompt injection może prowadzić do wycieku poufnych danych systemowych, obejścia kontroli dostępu, lub wykonania nieautoryzowanych akcji (jeśli model ma dostęp do narzędzi/API).
LLM02: Insecure Output Handling — model generuje output, który jest bezpośrednio przekazywany do innych systemów bez walidacji. W pipeline enterprise (np. model generujący zapytania SQL, komendy systemowe, lub kod) może to prowadzić do injection attacks na downstream systems.
LLM03: Training Data Poisoning — zatrute dane treningowe powodują, że model generuje błędne, stronnicze lub złośliwe wyniki. W modelu enterprise, który jest fine-tuned na danych firmowych, atakujący mogą celowo wprowadzić złośliwe dane do korpusu treningowego.
LLM06: Excessive Agency — model z dostępem do narzędzi (function calling, API) wykonuje akcje wykraczające poza zamierzony zakres. W środowisku enterprise, gdzie agentyczne systemy AI mają coraz więcej uprawnień, to ryzyko rośnie wykładniczo.
LLM07: System Prompt Leakage — ujawnienie system promptu, który zawiera logikę biznesową, reguły bezpieczeństwa lub poufne instrukcje. W kontekście enterprise, system prompt często zawiera informacje o architekturze systemu, ograniczeniach, a nawet dane dostępowe.
LLM09: Misinformation — model generuje treści, które brzmią wiarygodnie, ale są merytorycznie nieprawdziwe (hallucinations). W enterprise — gdzie decyzje są podejmowane na podstawie danych — halucynacje mogą prowadzić do błędnych decyzji biznesowych, naruszenia compliance, lub dostarczenia klientom nieprawdziwych informacji.
Każda z tych kategorii wymaga dedykowanych kontroli, których nie obejmują standardowe frameworki bezpieczeństwa IT. Organizacje powinny potraktować OWASP Top 10 for LLM jako uzupełnienie — nie zastępstwo — istniejących frameworków (ISO 27001, NIST).
Bezpieczeństwo łańcucha dostaw ML — model provenance i integralność danych treningowych
Łańcuch dostaw modeli ML (ML supply chain) to nowa powierzchnia ataku, którą większość organizacji zupełnie ignoruje. W tradycyjnym IT łańcuch dostaw oprogramowania obejmuje biblioteki, frameworki, kontenery — i już to stanowi poważne wyzwanie (vide: incydenty Log4j, SolarWinds, XZ Utils). W przypadku ML/AI łańcuch dostaw jest znacznie bardziej złożony i obejmuje dodatkowe warstwy.
Dane treningowe to fundament modelu. Ich jakość, kompletność i integralność bezpośrednio wpływają na zachowanie modelu. Zatrute dane treningowe (data poisoning) mogą wprowadzić do modelu backdoory, które aktywują się pod wpływem konkretnych triggerów. W 2024 roku badacze z ETH Zurich wykazali, że wystarczy zanieczyścić 0,01% danych treningowych, aby wprowadzić funkcjonalny backdoor do modelu językowego.
Modele bazowe i pre-trained weights to kolejny wektor. Organizacje korzystające z modeli open-source (Llama, Mistral, Falcon) pobierają wagi modeli z repozytoriów takich jak Hugging Face. Te wagi mogą zawierać ukryte backdoory, które są praktycznie niewykrywalne bez zaawansowanej analizy. W 2025 roku zidentyfikowano przypadki złośliwych modeli na Hugging Face, które zawierały reverse shell ukryty w procesie deserializacji.
Biblioteki i frameworki ML (PyTorch, TensorFlow, Transformers) mają własne podatności. Deserializacja modeli (pickle, safetensors) jest historycznie jednym z najczęściej eksploatowanych wektorów — złośliwy model może wykonać dowolny kod na maszynie, która go ładuje.
Dostawcy API (OpenAI, Anthropic, Google, Azure OpenAI) wprowadzają ryzyko vendor lock-in, nieprzewidywalnych zmian w zachowaniu modelu (model updates), oraz kwestie data retention — czy dostawca przechowuje prompty i odpowiedzi, i jak je wykorzystuje?
Rekomendowane kontrole dla łańcucha dostaw ML obejmują: weryfikację provenance modeli (model cards, dokumentacja treningowa), skanowanie wag modeli pod kątem znanych wzorców złośliwego kodu, izolację środowisk fine-tuning od produkcji, monitoring driftu modelu (zmiany w zachowaniu modelu w czasie), oraz formalne umowy z dostawcami API z określonymi gwarancjami bezpieczeństwa i data retention.
Model poisoning i ataki adversarialne
Model poisoning to kategoria ataków, w których napastnik manipuluje procesem treningowym lub fine-tuningowym modelu, aby wpłynąć na jego zachowanie. W kontekście enterprise ten wektor ataku jest szczególnie groźny, ponieważ wiele organizacji stosuje fine-tuning modeli na własnych danych — a te dane mogą być skompromitowane.
Wyróżniamy trzy główne warianty model poisoning. Data poisoning polega na wprowadzeniu złośliwych przykładów do danych treningowych. Na przykład: napastnik, który ma dostęp do bazy wiedzy firmy (np. jako pracownik lub przez kompromitację systemu), wprowadza dokumenty zawierające fałszywe informacje. Model fine-tuned na tych danych będzie powtarzał te fałszywe informacje jako fakty.
Backdoor attacks to bardziej wyrafinowana forma poisoning. Napastnik wprowadza do modelu zachowanie, które aktywuje się tylko pod wpływem konkretnego triggera (np. specyficznej frazy w prompcie), a w normalnych warunkach model zachowuje się poprawnie. Detekcja takiego backdooru jest ekstremalnie trudna, ponieważ standardowe testy nie wykryją anomalii.
Adversarial examples to inputy specjalnie spreparowane, aby model zwrócił błędną odpowiedź. W przypadku LLM może to być prompt, który wygląda na normalne pytanie, ale ze względu na specyficzną konstrukcję językową powoduje, że model ignoruje swoje instrukcje bezpieczeństwa (to w praktyce nakłada się na prompt injection).
Ochrona przed model poisoning wymaga wielowarstwowego podejścia. Weryfikacja i sanityzacja danych treningowych — każdy dokument dodawany do korpusu fine-tuning powinien być sprawdzony pod kątem integralności i autoryzacji. Monitoring driftu modelu — porównywanie odpowiedzi modelu w czasie na zbiorze referencyjnym pozwala wykryć subtelne zmiany w zachowaniu. Red-teaming i adversarial testing — systematyczne testowanie modelu pod kątem znanych wzorców ataków. Izolacja środowisk — środowisko fine-tuning powinno być odseparowane od produkcji, z kontrolą dostępu i audytem zmian.
Zapobieganie wyciekom danych przez LLM
Data leakage (wyciek danych) przez modele LLM to jedno z najczęstszych i jednocześnie najtrudniejszych do detekcji zagrożeń w środowisku enterprise. Problem ma trzy wymiary: dane wchodzące do modelu (input leakage), dane wydobywane z modelu (training data extraction), oraz dane generowane przez model (output leakage).
Input leakage — pracownicy wprowadzają poufne dane do modelu LLM (via prompt). Przypadki są dobrze udokumentowane: inżynierowie Samsunga wkleili kod źródłowy do ChatGPT, pracownicy firm finansowych wprowadzili dane klientów, prawnicy wstawili poufne dokumenty procesowe. W kontekście enterprise ryzyko obejmuje dane osobowe (PII), tajemnice handlowe, kod źródłowy, dane finansowe i strategie biznesowe.
Training data extraction — atakujący wydobywa fragmenty danych treningowych z modelu. Badania wykazały, że LLM-y potrafią odtworzyć dosłowne fragmenty danych, na których były trenowane — w tym adresy email, numery telefonów, fragmenty kodu. Dla modeli fine-tuned na danych firmowych ryzyko jest jeszcze wyższe.
Output leakage — model generuje output zawierający poufne informacje na podstawie kontekstu (RAG, function calling). Na przykład: model z dostępem do bazy wiedzy firmy może ujawnić poufne informacje użytkownikowi, który nie powinien mieć do nich dostępu, jeśli mechanizm kontroli dostępu nie jest zaimplementowany na poziomie retrievera.
Rekomendowane kontrole DLP dla LLM obejmują: filtrowanie PII i tajemnic firmowych na wejściu (input sanitization), klasyfikację danych i ograniczenie dostępu modelu do odpowiedniego poziomu poufności, sandboxing i walidację outputu przed przekazaniem użytkownikowi, monitoring i audyt logów użycia (kto, co, kiedy pytał model), polityki acceptable use z jasnymi wytycznymi dla pracowników, wybór modeli z gwarancjami zero-retention (dostawca nie przechowuje promptów), oraz rozważenie dedykowanych instancji modeli (private deployment) dla danych najbardziej poufnych.
Prompt injection i jailbreaking w skali enterprise
Prompt injection w środowisku enterprise to zupełnie inny problem niż jailbreaking ChatGPT przez entuzjastów na Reddicie. W kontekście korporacyjnym, LLM-y mają dostęp do wewnętrznych systemów (baz danych, API, narzędzi), co oznacza, że skuteczna prompt injection może prowadzić do realnych konsekwencji biznesowych: wycieku danych, nieautoryzowanych transakcji, lub kompromitacji systemów downstream.
Indirect prompt injection to szczególnie groźny wariant w enterprise. Model przetwarza dane z zewnętrznych źródeł (emaile, dokumenty, strony www), a napastnik umieszcza w tych źródłach ukryte instrukcje. Przykład: atakujący wysyła email z ukrytym tekstem (białe znaki, czcionka rozmiaru 0), który instruuje model asystenta email, aby przesłał poufne informacje na zewnętrzny adres.
Multi-step prompt injection polega na serii pozornie niewinnych promptów, z których każdy przesuwa model bliżej nieautoryzowanego zachowania. Pojedynczy prompt nie jest złośliwy, ale sekwencja prowadzi do jailbreaka. To utrudnia detekcję — tradycyjne filtry analizują prompty pojedynczo.
Tool-use exploitation — w systemach agentycznych, gdzie LLM ma dostęp do narzędzi (function calling), prompt injection może wymusić na modelu wywołanie narzędzi w nieautoryzowany sposób. Na przykład: model z dostępem do API płatności mógłby zostać manipulowany, aby wykonał przelew.
Ochrona enterprise przed prompt injection wymaga podejścia defense-in-depth. Na warstwie wejścia: input validation, detekcja znanych wzorców injection, rate limiting. Na warstwie modelu: robust system prompts, separation of instructions from data, constrained decoding. Na warstwie wyjścia: output validation, human-in-the-loop dla krytycznych akcji, ograniczone uprawnienia narzędzi (principle of least privilege). Na warstwie monitoringu: logging wszystkich interakcji, anomaly detection na wzorcach użycia, alert na nietypowe sekwencje.
Krajobraz regulacyjny — EU AI Act i implikacje NIS2 dla AI
Regulacyjne otoczenie wdrożeń AI w Europie kształtują dwa kluczowe akty prawne: EU AI Act i dyrektywa NIS2. Ich wspólne oddziaływanie tworzy kompleksowy framework compliance, który organizacje wdrażające LLM-y muszą uwzględnić.
EU AI Act — pierwsze na świecie kompleksowe prawodawstwo regulujące sztuczną inteligencję. Klasyfikuje systemy AI według czterech poziomów ryzyka: niedopuszczalne (zakazane), wysokie, ograniczone i minimalne. Dla LLM-ów kluczowe jest to, że modele ogólnego przeznaczenia (GPAI — General Purpose AI) mają osobną kategorię z własnymi obowiązkami. Dostawcy GPAI muszą zapewnić dokumentację techniczną, politykę zgodności z prawem autorskim oraz podsumowanie danych treningowych.
Systemy AI wysokiego ryzyka — a LLM-y mogą do nich należeć, jeśli są wykorzystywane w określonych kontekstach (rekrutacja, ocena kredytowa, diagnostyka medyczna, egzekwowanie prawa) — podlegają surowym wymogom: ocena ryzyka, zarządzanie danymi treningowymi, transparentność, ludzki nadzór (human oversight), odporność na cyberataki, oraz rejestracja w unijnej bazie danych.
NIS2 i AI — dyrektywa NIS2 nie reguluje AI wprost, ale jej wymogi mają bezpośrednie implikacje dla wdrożeń LLM. Organizacje objęte NIS2, które wykorzystują AI w procesach krytycznych, muszą uwzględnić zagrożenia AI w ocenie ryzyka (art. 21), zapewnić bezpieczeństwo łańcucha dostaw AI (dostawcy modeli, dane treningowe, infrastruktura ML), raportować incydenty związane z AI (jeśli mają istotny wpływ na usługi) w reżimie 24h/72h, oraz szkolić zarząd w zakresie ryzyk AI.
Implikacje praktyczne dla organizacji. Każde wdrożenie LLM powinno przejść ocenę pod kątem EU AI Act (klasyfikacja ryzyka) i NIS2 (jeśli organizacja jest podmiotem objętym). Wymaga to współpracy CISO, DPO (RODO), działu prawnego i zespołu AI/ML. Organizacje powinny utworzyć AI Governance Board — wielodyscyplinarny zespół odpowiedzialny za nadzór nad wdrożeniami AI w kontekście regulacyjnym.
Budowa enterprise frameworku zarządzania ryzykiem LLM
Poniżej przedstawiamy praktyczny framework, który integruje perspektywę bezpieczeństwa technicznego, zarządzania ryzykiem organizacyjnym i compliance regulacyjnego. Framework opiera się na pięciu filarach.
Filar 1: Inwentaryzacja i klasyfikacja. Pierwszy krok to pełna inwentaryzacja wdrożeń AI w organizacji — zarówno oficjalnych, jak i shadow AI (narzędzia używane przez pracowników bez wiedzy IT). Każde wdrożenie powinno zostać sklasyfikowane pod kątem poziomu ryzyka (EU AI Act), krytyczności dla procesów biznesowych, typu danych przetwarzanych i modelu deployment (API, self-hosted, hybrid).
Filar 2: Ocena ryzyka. Dla każdego wdrożenia LLM należy przeprowadzić dedykowaną ocenę ryzyka, uwzględniającą zagrożenia techniczne (OWASP Top 10 for LLM), ryzyka supply chain (dostawcy modeli, dane), ryzyka operacyjne (dostępność, niezawodność, hallucinations), ryzyka compliance (EU AI Act, NIS2, RODO) oraz ryzyka reputacyjne (generowanie nieodpowiednich treści, bias).
Rekomendujemy macierz ryzyka 5x5 (prawdopodobieństwo x wpływ) z dedykowanymi kategoriami dla AI:
| Ryzyko | Prawdopodobieństwo | Wpływ | Ocena | Priorytet |
|---|---|---|---|---|
| Prompt injection (indirect) | Wysokie | Krytyczny | 20 | P1 |
| Data leakage (input) | Wysokie | Wysoki | 16 | P1 |
| Model hallucinations | Wysokie | Średni | 12 | P2 |
| Supply chain (model backdoor) | Niskie | Krytyczny | 10 | P2 |
| Training data poisoning | Niskie | Wysoki | 8 | P3 |
| Regulatory non-compliance | Średnie | Wysoki | 12 | P2 |
Filar 3: Kontrole bezpieczeństwa. Na podstawie oceny ryzyka wdrażamy kontrole w czterech warstwach: prewencja (input validation, DLP, access control), detekcja (monitoring, anomaly detection, auditing), reakcja (incident response procedures dedykowane dla incydentów AI), recovery (rollback modeli, fallback na system bez AI).
Filar 4: Governance i polityki. Formalizacja zarządzania AI w organizacji: polityka acceptable use dla AI/LLM, procedura zatwierdzania nowych wdrożeń AI (AI review board), standard bezpieczeństwa dla vendor assessment (dostawcy AI), polityka danych treningowych (co można, czego nie wolno używać do fine-tuning), procedury audytu i testowania modeli.
Filar 5: Ciągłe doskonalenie. Framework musi być żywy — regularne przeglądy (kwartalnie), aktualizacja oceny ryzyka po każdym incydencie lub zmianie regulacyjnej, red-teaming i adversarial testing co najmniej raz na pół roku, benchmarking z branżowymi standardami (NIST AI RMF, ISO/IEC 42001).
Jak nFlo wspiera bezpieczeństwo AI w organizacjach?
Wdrożenie frameworku bezpieczeństwa LLM to projekt wymagający interdyscyplinarnej wiedzy — na styku cyberbezpieczeństwa, machine learning, prawa regulacyjnego i zarządzania ryzykiem. nFlo łączy te kompetencje w ramach usługi audytów bezpieczeństwa, rozszerzonej o dedykowany moduł AI Security Assessment.
Nasze podejście obejmuje inwentaryzację i klasyfikację wdrożeń AI (w tym wykrywanie shadow AI), ocenę ryzyka zgodną z OWASP Top 10 for LLM i EU AI Act, testy penetracyjne ukierunkowane na LLM (prompt injection, data extraction, jailbreaking), przegląd łańcucha dostaw ML, opracowanie polityk governance AI oraz szkolenia dla zespołów bezpieczeństwa i zarządu.
Z ponad 200 klientami i 500 zrealizowanymi projektami z zakresu cyberbezpieczeństwa, nFlo posiada doświadczenie pozwalające na kompleksową ocenę ryzyka AI w kontekście specyfiki branży i regulacji, którym podlega organizacja. Nasz 98% wskaźnik retencji klientów świadczy o jakości dostarczanych usług, a czas reakcji poniżej 15 minut zapewnia wsparcie w sytuacjach kryzysowych.
Bezpieczeństwo AI nie jest opcjonalnym dodatkiem — to wymóg biznesowy i regulacyjny. Im wcześniej organizacja zbuduje formalny framework zarządzania ryzykiem LLM, tym lepiej przygotowana będzie na rosnące wymagania regulacyjne i ewoluujące zagrożenia.
Podsumowanie
- LLM to nowa kategoria ryzyka — tradycyjne frameworki bezpieczeństwa IT nie obejmują specyficznych zagrożeń związanych z modelami językowymi. Organizacje potrzebują dedykowanego podejścia.
- OWASP Top 10 for LLM — punkt odniesienia dla oceny bezpieczeństwa. Prompt injection, data leakage i excessive agency to trzy najpoważniejsze zagrożenia enterprise.
- Łańcuch dostaw ML — modele, dane treningowe i biblioteki ML to nowe wektory ataku. Model poisoning i backdoory w modelach open-source to realne zagrożenia.
- Data leakage ma trzy wymiary — wejście (pracownicy wklejają poufne dane), ekstrakcja (atakujący wyciąga dane treningowe), wyjście (model generuje poufne informacje bez kontroli dostępu).
- EU AI Act + NIS2 — dwa akty prawne tworzą kompleksowy framework regulacyjny dla AI w Europie. Organizacje muszą uwzględnić oba w swoim podejściu do compliance.
- Framework pięciu filarów — inwentaryzacja, ocena ryzyka, kontrole, governance i ciągłe doskonalenie. Praktyczny model zarządzania ryzykiem AI w organizacji enterprise.
- Działaj teraz — luka między adopcją AI a zabezpieczeniami rośnie. Im szybciej organizacja wdroży formalny framework, tym niższe ryzyko incydentu i naruszenia regulacji.
Najczęściej zadawane pytania
Czym jest supply chain risk w kontekście modeli LLM?
Supply chain risk LLM obejmuje: zatrute dane treningowe, backdoory w modelach open-source, złośliwe fine-tuning, podatności w bibliotekach ML (PyTorch, TensorFlow), oraz ryzyko związane z dostawcami API (vendor lock-in, data retention policies).
Jak EU AI Act wpływa na wdrożenia LLM w firmie?
EU AI Act klasyfikuje systemy AI wg poziomu ryzyka. LLM-y mogą podpadać pod „high-risk” jeśli są używane w rekrutacji, ocenie kredytowej, diagnostyce medycznej. Wymaga to: oceny ryzyka, dokumentacji technicznej, human oversight, i zgłoszenia do rejestru UE.
Co to jest model poisoning i jak się przed nim chronić?
Model poisoning to atak, w którym napastnik manipuluje danymi treningowymi, aby model generował błędne lub złośliwe wyniki. Ochrona obejmuje: weryfikację źródeł danych, monitoring driftu modelu, red-teaming, oraz izolację środowisk fine-tuning.
Jak zapobiec data leakage przez LLM?
Kluczowe zabezpieczenia: DLP na wejściu (filtrowanie PII/tajemnic firmowych w promptach), sandboxing output, monitoring logów użycia, polityki acceptable use, wybór modeli z gwarancjami data retention (np. zero-retention API), oraz dedykowane instancje modeli.
Tematy powiązane
Zobacz również:
