Jak generatywna AI zmienia krajobraz cyberbezpieczeństwa
Od „klasycznego” IT security do bezpieczeństwa modeli
W klasycznym cyberbezpieczeństwie głównym obiektem ochrony były systemy: serwery, aplikacje webowe, urządzenia sieciowe, konta użytkowników. W świecie generatywnej AI do tego zestawu dochodzi nowy, bardzo specyficzny element: model i cały ekosystem wokół niego. To on generuje treści, podejmuje decyzje, integruje się z narzędziami, przetwarza dane wrażliwe.
W praktyce oznacza to kilka istotnych przesunięć. Po pierwsze, logika bezpieczeństwa nie jest już tylko w kodzie aplikacji, ale także w konfiguracji i „wychowaniu” modelu (prompty systemowe, dobór danych treningowych, filtry treści). Po drugie, atakujący mogą uderzać nie tylko w klasyczną infrastrukturę, ale też w sposób, w jaki użytkownik komunikuje się z modelem. Po trzecie, wiele decyzji, które kiedyś były jasno „if/else” w kodzie, dziś jest wynikiem probabilistycznego modelu – a to trudniejsze do przewidzenia i przetestowania tradycyjnymi metodami.
Ta zmiana sprawia, że model bezpieczeństwa musi obejmować: dane treningowe, parametry modelu, proces inferencji (generowania odpowiedzi), łańcuchy promptów (prompt chains), integracje z innymi systemami oraz reguły użycia (policy, governance). Sam firewall czy WAF nie wystarczy, jeśli aplikacja może zostać zmanipulowana jednym sprytnym promptem.
Nowe powierzchnie ataku: modele, dane treningowe, łańcuchy promptów
Generatywne AI otwiera nowe powierzchnie ataku, które nie występowały w tradycyjnych systemach (lub miały znikome znaczenie). Do najważniejszych należą:
- Model jako cel ataku – kradzież parametrów (model theft), rekonstrukcja modelu przez interfejs API, jailbreak obronnych mechanizmów modelu.
- Dane treningowe – zatruwanie danych (data poisoning), wstrzykiwanie złośliwych wzorców do zbiorów treningowych lub do danych wykorzystywanych w RAG, wyciek wrażliwych informacji, które nie powinny trafić do modelu.
- Łańcuchy promptów i orkiestracja – manipulacja promptem (prompt injection), przechwytywanie danych z kontekstu, eskalacja uprawnień poprzez integracje (np. narzędzia pozwalające modelowi wykonywać akcje).
- Integracje z narzędziami – gdy LLM może wywoływać API, pracować na plikach, wykonywać komendy, każdy błąd kontroli uprawnień staje się krytyczny.
Doświadczeni specjaliści od bezpieczeństwa rozpoznają w tym analogię do klasycznych ataków na API i bazy danych, ale z jedną różnicą: wejściem nie jest tylko JSON czy zapytanie SQL, ale również język naturalny, a odpowiedzi modelu są mniej deterministyczne. To utrudnia zarówno projektowanie zabezpieczeń, jak i budowę testów automatycznych.
Phishing klasyczny vs phishing wspierany przez LLM
W klasycznym phishingu atakujący często zdradzali się słabym językiem, literówkami, nieudolnym stylem. SOC i działy bezpieczeństwa budowały filtracje bazujące na wzorcach treści, reputacji nadawcy, prostych sygnaturach. Kampanie na masową skalę były dość łatwe do wykrycia i zablokowania.
Wraz z generatywną AI krajobraz zmienia się radykalnie. LLM potrafi przygotować dziesiątki tysięcy unikalnych, dopracowanych wiadomości w różnych językach, dopasowanych stylem do konkretnej branży czy nawet konkretnej osoby (na podstawie publicznych informacji). Z perspektywy SOC:
- klasyczne filtry treści oparte na prostych regułach mają mniejszą skuteczność,
- kampanie stają się bardziej zróżnicowane – trudniej je zgrupować jako jedną kampanię,
- rośnie znaczenie analizy behawioralnej (co użytkownik robi po kliknięciu, nie tylko co dostał).
Jeden z widocznych trendów: phishing staje się hiperpersonalizowany. LLM może wygenerować wiadomość, która odwołuje się do konkretnego projektu, konferencji, ostatniego posta na LinkedIn. Dla użytkownika wygląda to jak komunikacja „od kogoś, kto naprawdę wie, czym się zajmuje”. Oczekiwanie, że „szkolenia z phishingu” rozwiążą problem, staje się zbyt optymistyczne.
Dlaczego sama świadomość użytkowników już nie wystarcza
Od lat powtarza się radę: „szkol użytkowników, edukuj, buduj świadomość”. To nadal ma sens, ale skala trudności rośnie</strong. Użytkownik nie jest w stanie rozpoznać każdej złożonej manipulacji, szczególnie gdy wiadomość wygląda perfekcyjnie. Poza tym, w świecie generatywnej AI ofiarą ataku jest już nie tylko człowiek, ale także sam system AI – podatny na prompt injection, jailbreak czy wymuszenie ujawnienia poufnego kontekstu.
Specjaliści z obszaru cyberbezpieczeństwa muszą przesunąć akcent z „przerzucania odpowiedzialności” na użytkownika w stronę architektury odpornych systemów:
- silniejsze kontrolowanie tego, co trafia do modelu (input validation także na poziomie promptów),
- ograniczanie dostępnych funkcji i kontekstu, zamiast liczyć na „zdrowy rozsądek” użytkownika,
- monitoring zachowania modeli i użytkowników, automatyczne wykrywanie anomalii.
Kontrariański akcent: sama narracja „użytkownik jest najsłabszym ogniwem” bywa wygodnym usprawiedliwieniem. W świecie generatywnej AI najczęściej najsłabszym ogniwem staje się projekt systemu, który pozwala modelowi zrobić zbyt wiele przy zbyt słabej kontroli. Rolą specjalistów od cyberbezpieczeństwa jest przesunięcie ciężaru z edukacji użytkowników na inżynierię bezpieczeństwa.
Fundamentalne kompetencje – co z klasycznego cyberbezpieczeństwa się nie zestarzało
Uniwersalne koncepcje: modelowanie zagrożeń, ryzyko, kontrola dostępu
Mimo całego zamieszania wokół generatywnej AI, większość fundamentalnych koncepcji cyberbezpieczeństwa pozostaje aktualna. Modelowanie zagrożeń (threat modeling) jest wręcz bardziej potrzebne niż wcześniej: trzeba przeanalizować, kto i jak może wpłynąć na model, dane treningowe, pipeline MLOps czy integracje z zewnętrznymi narzędziami.
Kluczowe pozostaje także zarządzanie ryzykiem. AI wprowadza nowe rodzaje ryzyk (np. halucynacje modelu skutkujące złą decyzją biznesową), ale nadal trzeba je oceniać w kategoriach prawdopodobieństwo × wpływ, uwzględniając koszty mitygacji. Dla wielu firm większym ryzykiem będzie wyciek danych osobowych przez RAG niż hipotetyczny atak model theft na ich wewnętrzny model.
Kontrola dostępu, segmentacja sieci, podział na strefy zaufania – to wszystko przenosi się na grunt środowisk AI. Kto ma dostęp do danych treningowych? Kto może modyfikować prompty systemowe? Z jakich środowisk można wywoływać API modelu? Odpowiedź na te pytania to stara, dobra zasada najmniejszych uprawnień, tylko zastosowana do nowych komponentów.
Protokoły, sieci, systemy operacyjne – wciąż fundament
Rady typu „uciekaj z klasycznego security do AI, bo stare umiejętności będą bezwartościowe” są mocno przesadzone. Protokoły sieciowe, mechanizmy TCP/IP, DNS, TLS, podstawy administracji Linux/Windows – to wciąż fundament. Modele LLM nie żyją w próżni; działają na serwerach, w kontenerach, w chmurze, komunikują się przez API, logują dane do systemów, które ktoś musi rozumieć i zabezpieczać.
W praktyce często widoczny jest odwrotny problem: kandydaci z „AI w CV” mają powierzchowną wiedzę o prompt engineeringu, ale nie rozumieją, jak działa sieć, co to jest VPC, jak działają grupy bezpieczeństwa w chmurze, jak ustawić polityki IAM. Bez tego nie da się sensownie zabezpieczyć prawdziwego środowiska AI, bo większość zagrożeń wychodzi właśnie z konfiguracji infrastruktury.
Prosty test: jeśli ktoś nie umie wyjaśnić, jak wygląda przepływ ruchu od użytkownika do API modelu, przez load balancer, gateway, system uwierzytelniania, aż do backendu – trudno mu będzie skutecznie projektować mechanizmy bezpieczeństwa wokół AI.
Kiedy pogoń za „AI w CV” jest bez sensu
Popularna ścieżka: ktoś kończy kurs „AI dla każdego”, dopisuje do CV „zainteresowanie bezpieczeństwem AI”, po czym próbuje aplikować na role typu AI Security Engineer, mając luki w podstawach: brak zrozumienia OWASP Top 10, brak praktyki w analizie logów, brak obycia z Linuxem. Taka droga z reguły prowadzi do frustracji.
Szczególnie w rolach technicznych AI nie zastępuje podstaw. Sam kurs o prompt injection nie pomoże, jeśli kandydat nie rozumie, jak przechowywane są logi z zapytań do modelu, jak je korelować w SIEM, jak wdrożyć kontrolę dostępu do panelu administracyjnego. W efekcie pracodawcy zaczynają odróżniać „AI hype” od realnych kompetencji.
AI w CV ma sens, jeśli stoi za nim solidny „trzon” klasycznego security. Inaczej lepiej zainwestować najpierw w kompetencje ogólne: analiza incydentów, bezpieczeństwo aplikacji webowych, konfiguracja środowisk w chmurze. AI można dołożyć jako specjalizację, a nie fundament.
Jak ułożyć naukę: proporcje między klasycznym security a AI
Dla osób planujących karierę w cyberbezpieczeństwie z naciskiem na AI rozsądny plan może wyglądać następująco:
- 60–70% czasu – klasyczne bezpieczeństwo: sieci, systemy operacyjne, podstawy kryptografii, bezpieczeństwo aplikacji webowych, logowanie i monitoring, podstawy chmury (AWS/Azure/GCP).
- 20–30% czasu – specyficzne aspekty bezpieczeństwa AI: zagrożenia dla LLM, prompt injection, RAG security, wybrane frameworki i narzędzia.
- 10–20% czasu – zrozumienie podstaw ML/LLM (na poziomie potrzebnym do security, nie bycia pełnym data scientistem).
Taki rozkład pozwala uniknąć pułapki „AI bez fundamentu”. Dodatkowo daje elastyczność: jeśli rynek przesunie się mocno w stronę regulacji i governance, dobra znajomość klasycznego security i compliance będzie nadal bardzo cenna. AI jest dziś gorącym tematem, ale to, co przetrwa każde „przemeblowanie branży”, to zdolność rozumienia systemów jako całości.
Nowe role w cyberbezpieczeństwie związane z generatywną AI
AI Security Engineer / ML Security Engineer – na styku MLOps i security
Rola AI Security Engineer (czasem nazywana ML Security Engineer) powstaje w organizacjach, które poważnie traktują wdrażanie modeli na produkcję. To osoba, która łączy elementy DevOps/MLOps z klasycznym bezpieczeństwem aplikacji i infrastrukturą chmurową.
Do typowych zadań należą:
- projektowanie bezpiecznej architektury dla modeli – izolacja środowisk, segmentacja sieci, polityki IAM dla komponentów MLOps,
- weryfikacja bezpieczeństwa pipeline’u treningowego: skąd pochodzą dane, jak są walidowane, kto ma prawo je modyfikować,
- wdrażanie mechanizmów monitoringu i alertowania dla systemów AI (zarówno wydajność, jak i zachowania anomalne),
- współpraca z zespołem data science przy hardeningu modeli (np. filtry treści, ograniczenia kontekstu, polityki logowania).
W dużych firmach AI Security Engineer często pracuje wewnątrz zespołu platformowego (platform engineering), odpowiadając za spójne standardy bezpieczeństwa dla wszystkich projektów AI. W mniejszych organizacjach może to być „rozszerzona” rola DevOps/SecOps, który dodatkowo ogarnia tematy ML.
AI Red Teamer / Adversarial ML Specialist – ofensywne sprawdzanie modeli
AI Red Teamer to rozwinięcie klasycznych ról red team / pentester, ale skupione na systemach AI. Zadaniem takiej osoby jest aktywnie atakować modele i aplikacje korzystające z LLM, aby wykryć podatności zanim zrobią to przestępcy.
Zakres pracy obejmuje m.in.:
- przygotowywanie i wykonywanie ataków typu prompt injection, jailbreak, data exfiltration,
- testy odporności modeli na data poisoning – czy da się wstrzyknąć złośliwe dane i wpłynąć na zachowanie modelu,
- analizę podatności w łańcuchach wywołań (np. prompt → LLM → narzędzie/API → baza danych),
- współpracę z Blue Team przy opracowaniu scenariuszy ataku i procedur reakcji.
Dla osób z ofensywnym backgroundem (OSCP, doświadczenie w bug bounty) to naturalna ścieżka rozwoju: znane koncepcje (przekazywanie złośliwego payloadu, eskalacja uprawnień) są stosowane w nowym kontekście – języka naturalnego i modeli statystycznych.
AI Governance & Risk Specialist – na styku techniki, prawa i compliance
Wraz z rozwojem regulacji (np. europejski AI Act) pojawia się rola AI Governance & Risk Specialist. To osoba, która niekoniecznie głęboko wchodzi w techniczne szczegóły modeli, ale musi rozumieć je na tyle, by ocenić ryzyko i zapewnić zgodność z regulacjami, politykami wewnętrznymi i standardami branżowymi.
Do zadań tej roli należą m.in.:
AI Product Security Architect – bezpieczeństwo w projektowaniu usług opartych na modelach
Rosnąca liczba produktów z „AI w środku” wymusza pojawienie się roli, która łączy myślenie architekta rozwiązań z praktyką security. AI Product Security Architect pracuje blisko zespołów produktowych i UX, a nie tylko z infrastrukturą czy SOC.
Standardowy dzień takiej osoby to nie tylko diagramy sieci. To także:
- udział w projektowaniu funkcji z wykorzystaniem LLM – od razu z założonymi ograniczeniami bezpieczeństwa,
- przeglądy architektury całego łańcucha wywołań (front → backend → LLM → narzędzia → dane),
- definiowanie guardrails na poziomie produktu (co model może zrobić, jeśli użytkownik poprosi o coś niebezpiecznego),
- priorytetyzacja wymagań bezpieczeństwa vs. UX – np. kiedy logować pełne prompty, a kiedy je agresywnie anonimizować.
Popularna rada „zatrudnijmy prompt engineera i będzie bezpiecznie” zwykle się nie sprawdza w produktach o dużej skali. Potrzebna jest osoba, która rozumie konsekwencje decyzji produktowych: choćby tego, że domyślnie włączone zapisywanie historii czatów w B2B może stać się problemem przy audycie klienta korporacyjnego.
AI Privacy Engineer – ochrona danych w epoce LLM
W organizacjach, które już „przerobiły” klasyczne RODO/GPDR, pojawia się kolejny poziom trudności: modele, które mogą odtwarzać informacje z danych treningowych lub z sesji użytkownika. Tu wchodzi rola AI Privacy Engineer.
Zakres jej działania jest inny niż dotychczasowego specjalisty od privacy:
- ocena, czy dane trafiają do treningu, fine-tuningu czy wyłącznie do kontekstu (RAG) – i jakie to ma skutki prawne,
- projektowanie mechanizmów „zapominania” (data deletion) w środowisku, gdzie model może „nauczyć się” zbyt dużo,
- współpraca z zespołami prawno‑compliance przy Data Protection Impact Assessment (DPIA) specyficznym dla AI,
- przegląd polityk dostępu do logów promptów i odpowiedzi, łącznie z anonimizacją i pseudonimizacją.
Rada „nie wysyłajmy danych wrażliwych do chmury i po kłopocie” działa tylko w niewielkiej części przypadków. W praktyce biznes często potrzebuje dokładnie tych danych, które są najbardziej wrażliwe. AI Privacy Engineer ma za zadanie nie tyle „zakazać”, co zaprojektować realistyczny kompromis między użyciem a ochroną.
Kluczowe obszary techniczne bezpieczeństwa generatywnej AI
Bezpieczeństwo promptów i warstwy orkiestracji
Gdy mowa o bezpieczeństwie LLM, większość myśli o samym modelu. Tymczasem największe ryzyko często kryje się w warstwie orchestration: promptach systemowych, łańcuchach wywołań i integracjach.
W praktyce chodzi o kilka zagadnień:
- twarde ograniczenia w kodzie, a nie tylko w promptach („modelu, nie rób X” to nie jest kontrola bezpieczeństwa),
- separację promptów zaufanych (system/ developer) od danych użytkownika i źródeł zewnętrznych,
- bezpieczne projektowanie agentów i narzędzi (tools) – co właściwie może wywołać model i z jakimi parametrami,
- walidację wejść i wyjść modelu – tak samo jak w klasycznych aplikacjach waliduje się input z formularza.
Popularne zalecenie „napiszmy lepszy prompt systemowy i będzie bezpiecznie” zderza się z rzeczywistością przy pierwszym poważnym jailbreaku. Sama warstwa tekstowa jest zbyt krucha; bez mechanicznych barier w kodzie i infrastrukturze (limity akcji, whitelisting narzędzi, sandboxing) podatności będą powracać.
RAG Security – gdy wektorówka staje się nową bazą danych
Retrieval-Augmented Generation (RAG) jest dzisiaj domyślnym wzorcem wdrożeń LLM w firmach. Mało kto jednak traktuje wektorowe bazy danych tak serio jak klasyczne relacyjne bazy.
Przy RAG dochodzą m.in. takie ryzyka:
- brak kontroli dostępu na poziomie dokumentu lub fragmentu – każdy kontekst jest równorzędny dla modelu,
- wstrzyknięcie złośliwych treści do indeksu (np. przez upload dokumentów) i późniejsze prompt injection „z dokumentu”,
- przybliżone wyszukiwanie wektorowe ujawnia informacje podobne do danych, które teoretycznie nie powinny być powiązane,
- logi zapytań do wyszukiwarki wektorowej mogą zawierać treści dużo wrażliwsze niż same dokumenty.
Kontrariańska uwaga: rada „wrzućmy wszystko do RAG, nie trenujmy modelu na danych wrażliwych” jest sensowna tylko pod warunkiem, że RAG ma lepsze mechanizmy kontroli dostępu niż dotychczasowe repozytorium. W wielu organizacjach jest odwrotnie – powstaje nowy system, słabiej chroniony niż SharePoint czy DMS, a z wyższym potencjałem szkód przy wycieku.
Ataki na łańcuch dostaw modeli i pipeline MLOps
Klasyczne koncepcje „supply chain security” rozszerzają się na świat modeli: modele bazowe, checkpointy, dataset-y, pipeline’y treningowe. Dochodzą nowe wektory ataku, często niedostrzegane w działach bezpieczeństwa przyzwyczajonych do kodu aplikacji.
Typowe obszary ryzyka:
- pobieranie modeli z publicznych repozytoriów bez weryfikacji podpisów i pochodzenia,
- brak kontroli nad tym, kto może modyfikować pipeline treningowy (skrypty, konfiguracje, joby w chmurze),
- przechowywanie checkpointów modeli w nieszyfrowanych bucketach lub na współdzielonych dyskach,
- dane treningowe agregowane z wielu źródeł bez procesu walidacji i sanity checków.
Popularne hasło „używajmy open source, jest przejrzyste” nie chroni przed scenariuszem, w którym ktoś podmienia artefakt modelu w publicznym repo. Przejrzystość kodu to jedno, kontrola łańcucha dostaw – zupełnie inne zadanie. Dla security oznacza to konieczność włączenia komponentów MLOps do tych samych procesów, które obejmują CI/CD, dependency scanning i SBOM.
Monitoring zachowań modeli i detekcja anomalii
Tradycyjne monitorowanie skupia się na metrykach technicznych (latencja, błędy HTTP) i bezpieczeństwie infrastruktury. Przy generatywnej AI trzeba monitorować także zachowanie modeli.
Co podlega obserwacji:
- częstość i rodzaj odmów odpowiedzi (czy nagle spada skuteczność filtrów safety),
- wzorce podejrzanych promptów – np. nagły wzrost prób jailbreaku z jednego regionu,
- zmiany w typowych odpowiedziach po aktualizacji modelu lub danych,
- niestandardowe ścieżki w orkiestracji – np. agent zaczyna zbyt często wywoływać określone API.
Rada „logujmy wszystko” jest kusząca, ale szybko zabija budżet i rodzi problemy privacy. Bardziej sensowne podejście to warstwowe logowanie: pełne logi tylko w kontrolowanych scenariuszach (np. środowisko beta), w produkcji – silna anonimizacja, sampling, plus dedykowane metryki bezpieczeństwa agregowane na wyższym poziomie niż pojedynczy prompt.
Ochrona przed nadużyciami użytkowników i „dual use”
Generatywna AI szczególnie uwidacznia problem „dual use”: ten sam system może służyć do legalnej automatyzacji i do generowania treści przestępczych. Z perspektywy security to nie tylko filtr w modelu, ale też polityka użycia, nadzór i mechanizmy nadużyć.
Obszary wymagające uwagi:
- definiowanie acceptable use policy konkretnie pod AI (inne ryzyka niż przy klasycznych SaaS),
- systemy trust & safety – reagowanie na zgłoszenia nadużyć, blokady kont, limity na zapytania wysokiego ryzyka,
- wykrywanie automatyzowanych ataków z wykorzystaniem API LLM (np. masowe generowanie phishingu),
- zgodność z regulacjami branżowymi, które doprecyzowują, gdzie AI nie może być użyte (np. scoring kredytowy bez odpowiedniej przejrzystości).
Prosta rada „wrzućmy filtr treści i po sprawie” nie wytrzymuje zderzenia z użytkownikami zdeterminowanymi do obejścia ograniczeń. W praktyce potrzebne są trzy warstwy: modelowe filtry, kontrola biznesowa (limity, audyt) i przygotowane scenariusze reakcji, gdy użytkownik konsekwentnie próbuje wykorzystywać system w sposób szkodliwy.